* Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups
From: Nick Carter @ 2011-08-15 16:27 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Lamparter, netdev, Michał Mirosław, davem
In-Reply-To: <20110728084106.22166324@nehalam.ftrdhcpuser.net>
On 28 July 2011 16:41, Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
> On Wed, 27 Jul 2011 13:17:15 +0200
> David Lamparter <equinox@diac24.net> wrote:
>
>> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
>> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
>> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
>> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
>> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
>> > > > >> I am still undecided on this. Understand the need, but don't like idea
>> > > > >> of bridge behaving in non-conforming manner. Will see if IEEE 802 committee
>> > > > >> has any input.
>> > > > >
>> > > > > The patch doesn't make the bridge behave nonconformant. The default mask
>> > > > > is 0, which just keeps the old behaviour.
>> >
>> > P.S.: I'd like to once more stress this. In my opinion the patch should
>> > be merged because it provides desireable functionality at a small cost
>> > (one test, one knob) and __does not change any default behaviour__.
>>
>> Stephen, anything new on this?
>
> No.
> Don't like adding yet another hack user visible API which will have
> to be maintained for too long. But on the other hand I don't have
> a better solution at my finger tips. If better idea doesn't come
> along, then we can go with yours.
>
I have not noticed any other proposals and this thread has been open
for quite a while. Have we waited long enough ? If so can this patch
be taken ?
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH net-2.6] bonding:restore backup and inactive flag of slave
From: WANG Cong @ 2011-08-15 16:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <13dbe805d13bba461e50483c0162ce8bc1366204.1313403625.git.panweiping3@gmail.com>
On Mon, 15 Aug 2011 18:25:16 +0800, Weiping Pan wrote:
>
> diff --git a/drivers/net/bonding/bond_main.c
> b/drivers/net/bonding/bond_main.c index 38a83ac..3ed9827 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3419,9 +3419,27 @@ static int bond_xmit_hash_policy_l2(struct
sk_buff *skb, int count)
> static int bond_open(struct net_device *bond_dev) {
> struct bonding *bond = netdev_priv(bond_dev);
> + struct slave *slave;
> + int i;
>
> bond->kill_timers = 0;
>
> + // restore slave->backup and slave->inactive
Please use C-style comment.
> + read_lock(&bond->lock);
> + read_lock(&bond->curr_slave_lock);
> + if (bond->slave_cnt > 0) {
You can move the second read_lock() under this if().
^ permalink raw reply
* [PATCH net-next] ipv4: one more case for non-local saddr in ICMP
From: Julian Anastasov @ 2011-08-15 16:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Herbert Xu
May be there is one more case that we can avoid using
non-local source for ICMP errors: xfrm_lookup, num_xfrms = 0 when
reverse "Flow passes untransformed". Avoid using the input route
if xfrm_lookup returns same dst.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
In fact, should we use local IP in all cases when
sending ICMP? I'm asking it for the following case:
Large packet is forwarded but is rejected with ICMP FRAG
NEEDED. We usually send ICMP with local saddr instead of the
original non-local destination. What is the role of
this reverse check? May be after xfrm_decode_session_reverse
we should use 'fl4_dec.saddr = fl4->saddr;' so that xfrm_lookup
works with ICMP from local IP? What is right thing to do here?
I don't see code that looks in the embedded header...
--- net-next/net/ipv4/icmp.c 2011-08-15 18:42:21.289899686 +0300
+++ linux/net/ipv4/icmp.c 2011-08-15 18:38:25.816244111 +0300
@@ -379,7 +379,7 @@ static struct rtable *icmp_route_lookup(
int type, int code,
struct icmp_bxm *param)
{
- struct rtable *rt, *rt2;
+ struct rtable *rt, *rt2, *rt3;
struct flowi4 fl4_dec;
int err;
@@ -440,13 +440,18 @@ static struct rtable *icmp_route_lookup(
if (err)
goto relookup_failed;
+ rt3 = rt2;
rt2 = (struct rtable *) xfrm_lookup(net, &rt2->dst,
flowi4_to_flowi(&fl4_dec), NULL,
XFRM_LOOKUP_ICMP);
if (!IS_ERR(rt2)) {
- dst_release(&rt->dst);
- memcpy(fl4, &fl4_dec, sizeof(*fl4));
- rt = rt2;
+ if (rt2 == rt3 && rt) {
+ dst_release(&rt2->dst);
+ } else {
+ dst_release(&rt->dst);
+ memcpy(fl4, &fl4_dec, sizeof(*fl4));
+ rt = rt2;
+ }
} else if (PTR_ERR(rt2) == -EPERM) {
if (rt)
dst_release(&rt->dst);
^ permalink raw reply
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Marc Kleine-Budde @ 2011-08-15 16:13 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, Grant Likely, Scott Wood, PPC list,
Wolfgang Grandegger
In-Reply-To: <20110815150357.GM4926-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1648 bytes --]
On 08/15/2011 05:03 PM, Robin Holt wrote:
> Earlier, you had asked for a more specific name for the compatible
> property of the Freescale flexcan device. I still have not gotten a
> more specific answer. Hopefully Marc can give you more details about
> the flexcan implementations.
There are at least 2 versions of the flexcan ip core in the wild. Due to
lack of version numbers or other names I call them old and new here :).
The newer one supports rx fifo mode, whereas the older one doesn't. The
mainline flexcan driver just supports the new core [1]. The older core
is found on coldfire processors. I don't know if there are coldfire cpus
with the new flexcan core, too. The driver can be adopted to the old
core if needed.
The first cpus with the new core I got in touch with was the mx35
(arm11) and mx25 (arm9) both at the same time. Ask fsl which one was
released first. After this there was mx28 (arm9) and there should be an
mx53 (coretexa8) with flexcan too.
> Other than an agreement on the compatible property, I believe we have
> agreement on all the other code changes in these patches. Is this change
> acceptable as is and if we get a better resolution on the fsl,flexcan
> name later, we can update the documentation and driver then?
cheers, Marc
[1] http://lxr.linux.no/linux+v3.0.1/drivers/net/can/flexcan.c#L871
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH 2/2] net: minor update to Documentation/networking/scaling.txt
From: Will de Bruijn @ 2011-08-15 16:11 UTC (permalink / raw)
To: Rick Jones; +Cc: rdunlap, linux-doc, davem, netdev, therbert
In-Reply-To: <4E45B810.3000501@hp.com>
> I'd suggest simply "share a particular level in the memory hierarchy (Cache,
> NUMA node, etc)" and that way you get away from people asking nitpicky
> questions about where cache hierarchy counting starts, and at what level
> caches might be shared :)
>
> Apart from that, looks fine.
Thanks. It is already applied, so if you don't feel strongly about
this, I'll leave it as is (and take any nitpicky flak if that comes ;)
^ permalink raw reply
* Re: [PATCH] ethtool: RX NFC - Convert ip address to big endian.
From: Ben Hutchings @ 2011-08-15 16:00 UTC (permalink / raw)
To: nirmu; +Cc: netdev, Nir Muchtar
In-Reply-To: <1313422846-6550-1-git-send-email-nirmu@dev.mellanox.co.il>
On Mon, 2011-08-15 at 18:40 +0300, nirmu@dev.mellanox.co.il wrote:
> From: Nir Muchtar <nirmu@dev.mellanox.co.il>
>
> Signed-off-by: Nir Muchtar <nirmu@mellanox.com>
> ---
> Unless there's a reason that I'm missing to why the user
> is expected to specify ip addresses in big endian format.
>
> rxclass.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/rxclass.c b/rxclass.c
> index b227901..98d035b 100644
> --- a/rxclass.c
> +++ b/rxclass.c
> @@ -704,7 +704,7 @@ static int rxclass_get_ulong(char *str, unsigned long long *val, int size)
> return 0;
> }
>
> -static int rxclass_get_ipv4(char *str, __be32 *val)
> +static int rxclass_get_ipv4(char *str, u32 *val)
> {
> if (!inet_pton(AF_INET, str, val))
> return -1;
[...]
inet_pton() does the conversion to big-endian format.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] ethtool: RX NFC - Convert ip address to big endian.
From: nirmu @ 2011-08-15 15:40 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, Nir Muchtar, Nir Muchtar
From: Nir Muchtar <nirmu@dev.mellanox.co.il>
Signed-off-by: Nir Muchtar <nirmu@mellanox.com>
---
Unless there's a reason that I'm missing to why the user
is expected to specify ip addresses in big endian format.
rxclass.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/rxclass.c b/rxclass.c
index b227901..98d035b 100644
--- a/rxclass.c
+++ b/rxclass.c
@@ -704,7 +704,7 @@ static int rxclass_get_ulong(char *str, unsigned long long *val, int size)
return 0;
}
-static int rxclass_get_ipv4(char *str, __be32 *val)
+static int rxclass_get_ipv4(char *str, u32 *val)
{
if (!inet_pton(AF_INET, str, val))
return -1;
@@ -828,11 +828,11 @@ static int rxclass_get_val(char *str, unsigned char *p, u32 *flags,
break;
}
case OPT_IP4: {
- __be32 val;
+ u32 val;
err = rxclass_get_ipv4(str, &val);
if (err)
return -1;
- *(__be32 *)&p[opt->offset] = val;
+ *(__be32 *)&p[opt->offset] = htonl((u32)val);
if (opt->moffset >= 0)
*(__be32 *)&p[opt->moffset] = (__be32)mask;
break;
@@ -929,11 +929,11 @@ static int rxclass_get_mask(char *str, unsigned char *p,
break;
}
case OPT_IP4: {
- __be32 val;
+ u32 val;
err = rxclass_get_ipv4(str, &val);
if (err)
return -1;
- *(__be32 *)&p[opt->moffset] = ~val;
+ *(__be32 *)&p[opt->moffset] = ~htonl((u32)val);
break;
}
case OPT_MAC: {
--
1.7.1
^ permalink raw reply related
* Re: 3.1-rc1-git9: Reported regressions 2.6.39 -> 3.0
From: Paul E. McKenney @ 2011-08-15 15:37 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Florian Mickler,
Andrew Morton, Linus Torvalds, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <xuTC4jRtHbB.A.l4H.gMCSOB@chimera>
On Sun, Aug 14, 2011 at 09:02:27PM +0200, Rafael J. Wysocki wrote:
> [NOTE:
> We already have a bug entry for tracking regressions from 3.0:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=40982
>
> but there are no reports linked to it, mostly because Maciej is on vacation,
> but also because the frequency of reporting regressions has been low
> recently. So, if you're seeing a regression from 3.0, please let us know.]
>
> This message contains a list of some post-2.6.39 regressions introduced before
> 3.0, for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved post-2.6.39 regressions, please let us know
> either and we'll add them to the list. Also, please let us know if any
> of the entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply to
> this message with CCs to the people involved in reporting and handling the
> issue.
>
>
> Listed regressions statistics:
>
> Date Total Pending Unresolved
> ----------------------------------------
> 2011-08-14 63 22 19
>
>
> Unresolved regressions
> ----------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40282
> Subject : IP forwarding regression since 3.0-rc6
> Submitter : Stephan Seitz <stse+lkml-S0d6l+6kcjrOGKtSYHEJQ9HuzzzSOjJt@public.gmane.org>
> Date : 2011-07-25 12:51 (21 days old)
> Message-ID : <20110725T141145.GA.2ae38.stse-S0d6l+6kcjrOGKtSYHEJQ9HuzzzSOjJt@public.gmane.org>
> References : http://marc.info/?l=linux-kernel&m=131159880004908&w=2
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40172
> Subject : lockdep trace from post 3.0.
> Submitter : Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date : 2011-07-24 1:32 (22 days old)
> Message-ID : <20110724013257.GA6777-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> References : http://marc.info/?l=linux-kernel&m=131147120206819&w=2
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40092
> Subject : RCU stall in linux-3.0.0
> Submitter : Philip Armstrong <phil-awZZuG094qgqdlJmJB21zg@public.gmane.org>
> Date : 2011-07-25 21:44 (21 days old)
This one was due the the CPU's idea of the current time getting way
out of sync (as in more than a minute's worth of disagreement, which is
pretty impressive when you think about it). So what happened is that
one CPU decided that the current grace period was a full minute old
immediately, and thus started screaming piteously. John Stultz provided
a configuration workaround, and he and Thomas Gleixner would be working
out the long-term fix.
Thanx, Paul
^ permalink raw reply
* [PATCH] net_sched: fix port mirror/redirect stats reporting
From: jamal @ 2011-08-15 15:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev
commit 6a51508a01671114c236602d071d4bff53422c60
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon Aug 15 11:17:06 2011 -0400
[PATCH] net_sched: fix port mirror/redirect stats reporting
When a redirected or mirrored packet is dropped by the target
device we need to record statistics.
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 961386e..d5ef6ec 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -196,8 +196,7 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
skb2->skb_iif = skb->dev->ifindex;
skb2->dev = dev;
- dev_queue_xmit(skb2);
- err = 0;
+ err = dev_queue_xmit(skb2);
out:
if (err) {
^ permalink raw reply related
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-15 15:25 UTC (permalink / raw)
To: Grant Likely
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Marc Kleine-Budde, Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <CACxGe6vafc6mYyKCAO+HqkRPsZ3GmeVJnK+z8=BX_wQQMG4LmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Aug 15, 2011 at 09:13:50AM -0600, Grant Likely wrote:
> On Mon, Aug 15, 2011 at 9:03 AM, Robin Holt <holt-sJ/iWh9BUns@public.gmane.org> wrote:
> > Grant,
> >
> > Earlier, you had asked for a more specific name for the compatible
> > property of the Freescale flexcan device. I still have not gotten a
> > more specific answer. Hopefully Marc can give you more details about
> > the flexcan implementations.
>
> If there is no ip core version, then just stick with the
> fsl,<soc>-flexcan name and drop "fsl,flexcan". Marketing may say
> flexcan is flexcan, but hardware engineers like to change things.
> Trying to be too generic in compatible values will just lead to
> problems in the future.
Thanks,
Robin
^ permalink raw reply
* Re: Fw: [Bug 39132] Starting with 3.0.0-rc6, masquerading seems to be broken.
From: Julian Anastasov @ 2011-08-15 15:27 UTC (permalink / raw)
To: David Hill; +Cc: Florian Mickler, netdev, David Miller, bugzilla-daemon
In-Reply-To: <8A188C9C23A54337A5A276BAE29DC6E0@delorimier>
Hello,
On Fri, 5 Aug 2011, David Hill wrote:
> Hello Julian,
>
> I'm not using TPROXY and I've used a blank firewall with only masquerading
> and reproduced the issue.
> Nothing is in NAT/mangle nor OUTPUT but the rules mentionned in the attached
> files to this bug.
>
> Francis Whittle (Comment #18) has the same issue.
>
> > Hello,
> >
> > On Thu, 4 Aug 2011, Florian Mickler wrote:
> >
> > > Can someone take a look at this regression?
> > >
> > > Begin forwarded message:
> > >
> > > Date: Thu, 28 Jul 2011 04:51:12 GMT
> > > From: bugzilla-daemon@bugzilla.kernel.org
> > > To: florian@mickler.org
> > > Subject: [Bug 39132] Starting with 3.0.0-rc6, masquerading seems to be
> > > broken.
> > >
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=39132
> >
> > So, problem points again to
> > "Fix ip_route_me_harder triggering ip_rt_bug" ? May be
> > David C. Hill or Florian can provide some information, eg. is
> > tproxy used, what NAT rules are used, any rules in OUTPUT
> > hooks (NAT/mangle) and which packets are dropped.
May be it is a sequence of two problems. I now
checked the tcpdump log from Francis Whittle. The
"seq 352:1792" packet at 18:44:29.235154 that is not
SNAT-ed is long, can it be some PMTU event that triggers
ICMP response to the internal host? Because I see changes
in MSS. May be rc5 triggers ICMP FRAG NEEDED while rc6
does not. It can happen because:
1. ICMP uses non-local iph->saddr when XFRM is compiled,
reverse lookup fails with ENOENT but fl4->saddr is
already damaged with the original daddr (non-local).
Fix is here: http://marc.info/?t=131118984300003&r=1&w=2
2. The patched ip_route_me_harder between 3.0-rc5 and
3.0-rc6 expects that sockets always provide local address.
This is wrong for some cases such as TCP (uses different
SOCK_RAW socket for some packets and can cause problem
for tproxy), RAW (can use spoofed sources) and now the
ICMP code that incorrectly provides non-local address.
Fix is here: http://marc.info/?t=131274411600001&r=1&w=2
I hope (any of) these two fixes should solve the
masquerading problems. If that is not true, tcpdump from rc5
would be helpful for comparison.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Grant Likely @ 2011-08-15 15:13 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Marc Kleine-Budde, Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <20110815150357.GM4926-sJ/iWh9BUns@public.gmane.org>
On Mon, Aug 15, 2011 at 9:03 AM, Robin Holt <holt-sJ/iWh9BUns@public.gmane.org> wrote:
> Grant,
>
> Earlier, you had asked for a more specific name for the compatible
> property of the Freescale flexcan device. I still have not gotten a
> more specific answer. Hopefully Marc can give you more details about
> the flexcan implementations.
If there is no ip core version, then just stick with the
fsl,<soc>-flexcan name and drop "fsl,flexcan". Marketing may say
flexcan is flexcan, but hardware engineers like to change things.
Trying to be too generic in compatible values will just lead to
problems in the future.
g.
^ permalink raw reply
* Re: [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Michal Schmidt @ 2011-08-15 15:13 UTC (permalink / raw)
To: eilong; +Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <1313411585.31417.35.camel@lb-tlvb-eilong.il.broadcom.com>
On 08/15/2011 02:33 PM, Eilon Greenstein wrote:
> On Mon, 2011-08-15 at 04:59 -0700, Michal Schmidt wrote:
>> and bnx2x_init_vn_minmax() calls bnx2x_extract_max_cfg() on the given
>> VN, so it seems that the warning can be produced for a non-current VN.
>
> You are right, only one function (the PMF) will call this code for all
> functions. But I suspect that if you have zero values, you will have
> them for all VNs - is that the case?
A tester reported getting only these 4 messages with the patch applied:
[bnx2x_extract_max_cfg:1074(eth4)]Illegal configuration detected for Max
BW on vn 2 - using 100 instead
[bnx2x_extract_max_cfg:1074(eth5)]Illegal configuration detected for Max
BW on vn 2 - using 100 instead
[bnx2x_extract_max_cfg:1074(eth6)]Illegal configuration detected for Max
BW on vn 3 - using 100 instead
[bnx2x_extract_max_cfg:1074(eth7)]Illegal configuration detected for Max
BW on vn 3 - using 100 instead
This suggests that VNs 0 and 1 had non-zero Max BW configuration.
Michal
^ permalink raw reply
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-15 15:03 UTC (permalink / raw)
To: Grant Likely, Marc Kleine-Budde
Cc: Robin Holt, Kumar Gala, Wolfgang Grandegger, U Bhaskar-B22300,
Scott Wood, socketcan-core, netdev, PPC list, devicetree-discuss
In-Reply-To: <1313138752-24006-4-git-send-email-holt@sgi.com>
Grant,
Earlier, you had asked for a more specific name for the compatible
property of the Freescale flexcan device. I still have not gotten a
more specific answer. Hopefully Marc can give you more details about
the flexcan implementations.
Other than an agreement on the compatible property, I believe we have
agreement on all the other code changes in these patches. Is this change
acceptable as is and if we get a better resolution on the fsl,flexcan
name later, we can update the documentation and driver then?
Thanks,
Robin
On Fri, Aug 12, 2011 at 03:45:49AM -0500, Robin Holt wrote:
> This patch cleans up the documentation of the device-tree binding for
> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
> properties are not used by the driver so we are removing them.
>
> Signed-off-by: Robin Holt <holt@sgi.com>
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>,
> To: Wolfgang Grandegger <wg@grandegger.com>,
> To: U Bhaskar-B22300 <B22300@freescale.com>
> To: Scott Wood <scottwood@freescale.com>
> To: Grant Likely <grant.likely@secretlab.ca>
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: socketcan-core@lists.berlios.de,
> Cc: netdev@vger.kernel.org,
> Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
> Cc: devicetree-discuss@lists.ozlabs.org
> ---
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 ++++----------------
> arch/powerpc/boot/dts/p1010rdb.dts | 10 +---
> arch/powerpc/boot/dts/p1010si.dtsi | 10 +--
> 3 files changed, 17 insertions(+), 64 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> index 1a729f0..80a78a9 100644
> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> @@ -1,61 +1,22 @@
> -CAN Device Tree Bindings
> -------------------------
> -2011 Freescale Semiconductor, Inc.
> +Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
>
> -fsl,flexcan-v1.0 nodes
> ------------------------
> -In addition to the required compatible-, reg- and interrupt-properties, you can
> -also specify which clock source shall be used for the controller.
> +Required properties:
>
> -CPI Clock- Can Protocol Interface Clock
> - This CLK_SRC bit of CTRL(control register) selects the clock source to
> - the CAN Protocol Interface(CPI) to be either the peripheral clock
> - (driven by the PLL) or the crystal oscillator clock. The selected clock
> - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> - The PRESDIV field of CTRL(control register) controls a prescaler that
> - generates the Serial Clock (Sclock), whose period defines the
> - time quantum used to compose the CAN waveform.
> +- compatible : Should be "fsl,<processor>-flexcan" and "fsl,flexcan"
>
> -Can Engine Clock Source
> - There are two sources for CAN clock
> - - Platform Clock It represents the bus clock
> - - Oscillator Clock
> + An implementation should also claim any of the following compatibles
> + that it is fully backwards compatible with:
>
> - Peripheral Clock (PLL)
> - --------------
> - |
> - --------- -------------
> - | |CPI Clock | Prescaler | Sclock
> - | |---------------->| (1.. 256) |------------>
> - --------- -------------
> - | |
> - -------------- ---------------------CLK_SRC
> - Oscillator Clock
> + - fsl,p1010-flexcan
>
> -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> - the peripheral clock. PLL clock is fed to the
> - prescaler to generate the Serial Clock (Sclock).
> - Valid values are "oscillator" and "platform"
> - "oscillator": CAN engine clock source is oscillator clock.
> - "platform" The CAN engine clock source is the bus clock
> - (platform clock).
> +- reg : Offset and length of the register set for this device
> +- interrupts : Interrupt tuple for this device
>
> -- fsl,flexcan-clock-divider : for the reference and system clock, an additional
> - clock divider can be specified.
> -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> +Example:
>
> -Note:
> - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> - - P1010 does not have oscillator as the Clock Source.So the default
> - Clock Source is platform clock.
> -Examples:
> -
> - can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> + can@1c000 {
> + compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-source = "platform";
> - fsl,flexcan-clock-divider = <2>;
> - clock-frequency = <fixed by u-boot>;
> };
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> index 6b33b73..d6c669c 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dts
> +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> @@ -23,6 +23,8 @@
> ethernet2 = &enet2;
> pci0 = &pci0;
> pci1 = &pci1;
> + can0 = &can0;
> + can1 = &can1;
> };
>
> memory {
> @@ -169,14 +171,6 @@
> };
> };
>
> - can0@1c000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> - can1@1d000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> usb@22000 {
> phy_type = "utmi";
> };
> diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
> index 7f51104..f00076b 100644
> --- a/arch/powerpc/boot/dts/p1010si.dtsi
> +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> @@ -140,20 +140,18 @@
> interrupt-parent = <&mpic>;
> };
>
> - can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> + can0: can@1c000 {
> + compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> - can1@1d000 {
> - compatible = "fsl,flexcan-v1.0";
> + can1: can@1d000 {
> + compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> reg = <0x1d000 0x1000>;
> interrupts = <61 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> L2: l2-cache-controller@20000 {
> --
> 1.7.2.1
^ permalink raw reply
* Re: igb transmit queue timed out, rcu_sched_state detected stall
From: Peter Neal @ 2011-08-15 14:33 UTC (permalink / raw)
To: netdev
In-Reply-To: <CALJvf+qLZyXpxfDR-3aJVn2Qf558SKPc85NpQOosafqxCUC46w@mail.gmail.com>
I have updated the BIOS, iproute2, e1000e and igb drivers, but am
still seeing issues, any thoughts?
Thanks,
Pete
[ 7765.881893] bnx2 0000:0b:00.0: eth25: NIC Copper Link is Up, 1000
Mbps full duplex, receive & transmit flow control ON
[ 7767.395912] bnx2 0000:0b:00.0: eth25: NIC Copper Link is Down
[ 7769.832448] bnx2 0000:0b:00.0: eth25: NIC Copper Link is Up, 1000
Mbps full duplex, receive & transmit flow control ON
[ 7778.124580] igb: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7783.001120] igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7783.900216] igb: eth4 NIC Link is Down
[ 7786.204560] igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7788.168523] igb: eth18 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7789.414458] igb: eth18 NIC Link is Down
[ 7791.702958] igb: eth18 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7794.188210] igb: eth12 NIC Link is Down
[ 7796.432599] igb: eth12 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7826.864941] e1000e: eth21 NIC Link is Up 1000 Mbps Full Duplex,
Flow Control: Rx/Tx
[ 7836.544159] igb: eth17 NIC Link is Down
[ 7864.112307] igb: eth6 NIC Link is Down
[ 7917.072196] igb: eth16 NIC Link is Down
[ 7919.356618] igb: eth16 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7920.848574] igb: eth10 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7926.272173] igb: eth4 NIC Link is Down
[ 7965.212587] igb: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7966.200164] igb: eth6 NIC Link is Down
[ 7968.742002] igb: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7971.112151] e1000e: eth20 NIC Link is Down
[ 7973.084709] igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 7973.452998] e1000e: eth20 NIC Link is Up 1000 Mbps Full Duplex,
Flow Control: Rx/Tx
[ 7974.300193] igb: eth4 NIC Link is Down
[ 7976.616567] igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
[ 8041.200005] INFO: rcu_sched_state detected stall on CPU 2 (t=15000 jiffies)
[ 8041.835999] INFO: rcu_bh_state detected stall on CPU 2 (t=15000 jiffies)
[ 8060.251724] bnx2 0000:0b:00.0: eth25: NIC Copper Link is Down
[ 8096.268889] bnx2 0000:0b:00.0: eth25: NIC Copper Link is Up, 1000
Mbps full duplex, receive & transmit flow control ON
[ 8161.920070] INFO: task irqbalance:1777 blocked for more than 120 seconds.
[ 8162.001213] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8162.094833] irqbalance D ffff88042e9abd50 0 1777 1 0x00000000
[ 8162.179119] ffff88042e9abd50 0000000000000086 ffff88042e9abd50
ffff88042ec6a8e0
[ 8162.267569] 0000000000012680 ffff88042b5fdfd8 ffff88042b5fdfd8
0000000000012680
[ 8162.356047] ffff88042e9abd50 ffff88042b5fc010 0000000100000000
ffff88042b995f60
[ 8162.444498] Call Trace:
[ 8162.473641] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8162.548540] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8162.611996] [<ffffffff81269ca6>] ? dev_load+0x9/0x70
[ 8162.672333] [<ffffffff8126b017>] ? dev_ioctl+0x4ad/0x62e
[ 8162.736839] [<ffffffff8125844c>] ? sock_do_ioctl+0x2f/0x36
[ 8162.803415] [<ffffffff81258853>] ? sock_ioctl+0x205/0x212
[ 8162.868959] [<ffffffff810f3d2d>] ? get_empty_filp+0x9c/0x12b
[ 8162.937616] [<ffffffff810ff9bb>] ? do_vfs_ioctl+0x467/0x4b4
[ 8163.005235] [<ffffffff81259ed4>] ? sock_alloc_file+0xae/0x10c
[ 8163.074938] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8163.138393] [<ffffffff810ffa53>] ? sys_ioctl+0x4b/0x70
[ 8163.200810] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8163.274672] INFO: task snmpd:1797 blocked for more than 120 seconds.
[ 8163.350609] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8163.444228] snmpd D ffff88042aa4d890 0 1797 1 0x00000000
[ 8163.528516] ffff88042aa4d890 0000000000000086 ffff88042aa4d890
ffff88042ec6a8e0
[ 8163.616962] 0000000000012680 ffff88042d7b7fd8 ffff88042d7b7fd8
0000000000012680
[ 8163.705415] ffff88042aa4d890 ffff88042d7b6010 0000000100000000
ffff88042b995f60
[ 8163.793870] Call Trace:
[ 8163.823001] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8163.897900] [<ffffffff810fa4b3>] ? dget+0x12/0x1e
[ 8163.955115] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8164.018572] [<ffffffff8126aba4>] ? dev_ioctl+0x3a/0x62e
[ 8164.082034] [<ffffffff81103734>] ? dput+0x29/0xe9
[ 8164.139253] [<ffffffff810eb735>] ? get_partial_node+0x15/0x7b
[ 8164.208949] [<ffffffff810f3cfa>] ? get_empty_filp+0x69/0x12b
[ 8164.277606] [<ffffffff8125844c>] ? sock_do_ioctl+0x2f/0x36
[ 8164.344186] [<ffffffff81258853>] ? sock_ioctl+0x205/0x212
[ 8164.409721] [<ffffffff810f3d2d>] ? get_empty_filp+0x9c/0x12b
[ 8164.478377] [<ffffffff810ff9bb>] ? do_vfs_ioctl+0x467/0x4b4
[ 8164.545996] [<ffffffff81259ed4>] ? sock_alloc_file+0xae/0x10c
[ 8164.615696] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8164.679156] [<ffffffff810ffa53>] ? sys_ioctl+0x4b/0x70
[ 8164.741574] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8164.815438] INFO: task sshd:806 blocked for more than 120 seconds.
[ 8164.889300] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8164.982918] sshd D ffff88042d62e630 0 806 1814 0x00000000
[ 8165.067195] ffff88042d62e630 0000000000000086 ffff88042d62e630
ffff88042edb5890
[ 8165.155645] 0000000000012680 ffff8803fa8fffd8 ffff8803fa8fffd8
0000000000012680
[ 8165.244109] ffff88042d62e630 ffff8803fa8fe010 0000000100000000
ffff88042b995f60
[ 8165.332561] Call Trace:
[ 8165.361699] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8165.436600] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8165.500064] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8165.565602] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8165.635298] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8165.706044] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8165.779901] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8165.845439] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8165.907854] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8165.975475] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8166.048289] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8166.112785] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8166.176242] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8166.250105] INFO: task sshd:807 blocked for more than 120 seconds.
[ 8166.323964] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8166.417581] sshd D ffff88042a491470 0 807 1814 0x00000000
[ 8166.501865] ffff88042a491470 0000000000000086 ffff88042a491470
ffff88042edb73d0
[ 8166.590321] 0000000000012680 ffff8803e7e37fd8 ffff8803e7e37fd8
0000000000012680
[ 8166.678785] ffff88042a491470 ffff8803e7e36010 0000000100000000
ffff88042b995f60
[ 8166.767243] Call Trace:
[ 8166.796385] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8166.871289] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8166.934748] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8167.000284] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8167.069987] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8167.140727] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8167.214584] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8167.280121] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8167.342543] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8167.410162] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8167.482978] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8167.547477] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8167.610937] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8167.684797] INFO: task sshd:808 blocked for more than 120 seconds.
[ 8167.758654] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8167.852272] sshd D ffff88042a494420 0 808 1814 0x00000000
[ 8167.936556] ffff88042a494420 0000000000000082 ffff88042a494420
ffff88042e9a8000
[ 8168.025020] 0000000000012680 ffff88042daa9fd8 ffff88042daa9fd8
0000000000012680
[ 8168.113482] ffff88042a494420 ffff88042daa8010 0000000100000000
ffff88042b995f60
[ 8168.201947] Call Trace:
[ 8168.231085] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8168.305981] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8168.369438] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8168.434979] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8168.504672] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8168.575409] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8168.649267] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8168.714811] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8168.777228] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8168.844848] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8168.917663] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8168.982164] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8169.045621] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8169.119480] INFO: task sshd:809 blocked for more than 120 seconds.
[ 8169.193337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8169.286959] sshd D ffff88042b8186d0 0 809 1814 0x00000000
[ 8169.371232] ffff88042b8186d0 0000000000000086 ffff88042b8186d0
ffff88042e9a8da0
[ 8169.459683] 0000000000012680 ffff8803ef68bfd8 ffff8803ef68bfd8
0000000000012680
[ 8169.548141] ffff88042b8186d0 ffff8803ef68a010 0000000100000000
ffff88042b995f60
[ 8169.636603] Call Trace:
[ 8169.665736] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8169.740634] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8169.804095] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8169.869632] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8169.939330] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8170.010066] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8170.083929] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8170.149469] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8170.211886] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8170.279502] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8170.352323] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8170.416818] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8170.480274] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8170.554131] INFO: task smtpserver.pl:815 blocked for more than 120 seconds.
[ 8170.637354] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8170.730974] smtpserver.pl D ffff88042b81caf0 0 815 31144 0x00000004
[ 8170.815252] ffff88042b81caf0 0000000000000082 ffff88042b81caf0
ffff88042ee03d50
[ 8170.903706] 0000000000012680 ffff88042e929fd8 ffff88042e929fd8
0000000000012680
[ 8170.992174] ffff88042b81caf0 ffff88042e928010 0000000100000000
ffff88042b995f60
[ 8171.080630] Call Trace:
[ 8171.109767] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8171.184668] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8171.248126] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8171.313665] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8171.383361] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8171.454104] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8171.527962] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8171.593500] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8171.655915] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8171.723538] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8171.796356] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8171.860854] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8171.924311] [<ffffffff81259f56>] ? sock_map_fd+0x24/0x2d
[ 8171.988812] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8172.062672] INFO: task sshd:823 blocked for more than 120 seconds.
[ 8172.136527] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8172.230147] sshd D ffff88042a496d00 0 823 1814 0x00000000
[ 8172.314431] ffff88042a496d00 0000000000000082 ffff88042a496d00
ffff88042edb73d0
[ 8172.402881] 0000000000012680 ffff88042a9cdfd8 ffff88042a9cdfd8
0000000000012680
[ 8172.491319] ffff88042a496d00 ffff88042a9cc010 0000000100000000
ffff88042b995f60
[ 8172.579783] Call Trace:
[ 8172.608922] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8172.683819] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8172.747277] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8172.812815] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8172.882512] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8172.953247] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8173.027105] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8173.092645] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8173.155065] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8173.222680] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8173.295499] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8173.360015] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8173.423471] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8173.497329] INFO: task sshd:872 blocked for more than 120 seconds.
[ 8173.571185] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8173.664810] sshd D ffff88042d6286d0 0 872 1814 0x00000000
[ 8173.749088] ffff88042d6286d0 0000000000000082 ffff88042d6286d0
ffff88042edb5890
[ 8173.837545] 0000000000012680 ffff8803eabf3fd8 ffff8803eabf3fd8
0000000000012680
[ 8173.926005] ffff88042d6286d0 ffff8803eabf2010 0000000100000000
ffff88042b995f60
[ 8174.014447] Call Trace:
[ 8174.043585] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8174.118483] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8174.181943] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8174.247482] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8174.317178] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8174.387918] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8174.461779] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8174.527317] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8174.589734] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8174.657352] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8174.730176] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8174.794674] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8174.858132] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8174.931986] INFO: task sshd:873 blocked for more than 120 seconds.
[ 8175.005847] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 8175.099461] sshd D ffff88042a494af0 0 873 1814 0x00000000
[ 8175.183739] ffff88042a494af0 0000000000000082 ffff88042a494af0
ffff88042edb73d0
[ 8175.272197] 0000000000012680 ffff8804084f7fd8 ffff8804084f7fd8
0000000000012680
[ 8175.360649] ffff88042a494af0 ffff8804084f6010 0000000100000000
ffff88042b995f60
[ 8175.449106] Call Trace:
[ 8175.478243] [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[ 8175.553145] [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[ 8175.616602] [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[ 8175.682139] [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[ 8175.751838] [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[ 8175.822579] [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[ 8175.896438] [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[ 8175.961976] [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[ 8176.024393] [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[ 8176.092023] [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[ 8176.164846] [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[ 8176.229343] [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[ 8176.292800] [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[ 8221.320008] INFO: rcu_sched_state detected stall on CPU 2 (t=60030 jiffies)
[ 8221.955999] INFO: rcu_bh_state detected stall on CPU 2 (t=60030 jiffies)
[ 8401.440001] INFO: rcu_sched_state detected stall on CPU 2 (t=105060 jiffies)
[ 8402.076002] INFO: rcu_bh_state detected stall on CPU 2 (t=105060 jiffies)
^ permalink raw reply
* Re: [RFC PATCH v2] net: dm9000: add support for device tree probing
From: Jamie Iles @ 2011-08-15 14:21 UTC (permalink / raw)
To: Daniel Morsing
Cc: devicetree-discuss, netdev, Mark Brown, Ben Dooks,
David S. Miller
In-Reply-To: <1313343252-19634-1-git-send-email-daniel.morsing@gmail.com>
Hi Daniel,
On Sun, Aug 14, 2011 at 07:34:12PM +0200, Daniel Morsing wrote:
> This patch adds support for probing the dm9000 driver through device
> trees.
>
> The patch works by supplying its own platform_data struct when probed
> via device tree. This allows us to rely on the existing options parsing
> in the driver and avoid ifdeffery in the probe function.
>
> Signed-off-by: Daniel Morsing <daniel.morsing@gmail.com>
> ---
> Currently there are no users of this functionality, but once support for
> DT on OMAP3 matures, I plan to migrate the devkit8000 board to DT.
>
> Changes since v1:
> - Changed the binding with input from Grant Likely.
> - Make explicit what the bindings do instead of refering
> to linux specific flags.
> - Length check the mac address read so we don't copy random data.
> - simplify parsing of the device tree.
> - Add relevant driver maintainers to CC (sorry about that)
>
> Documentation/devicetree/bindings/net/dm9000.txt | 42 +++++++++++
> drivers/net/dm9000.c | 83 +++++++++++++++++++++-
> 2 files changed, 122 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/dm9000.txt
>
> diff --git a/Documentation/devicetree/bindings/net/dm9000.txt b/Documentation/devicetree/bindings/net/dm9000.txt
> new file mode 100644
> index 0000000..cbbdb3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dm9000.txt
> @@ -0,0 +1,42 @@
> +Davicom DM9000 ethernet controller
> +
> +Required properties:
> +
> + - compatible : Should be "davicom,dm9000"
> +
> + - interrupts : Interrupt controller specific encoding, which specifies 1
> + or 2 interrupts. The first interrupt is for rx/tx and is required by the
> + driver to function. The second interrupt is for wake on lan support
> + and is optional.
> +
> + - reg : 2 Physical address specifiers, where the first specifies the address
> + register of device, and the second specifies the data register of the device
> +
> +Optional properties:
> +
> + - local-mac-address : Binary data specifying a mac address override
> +
> + - reg-io-width : one cell specifying the width of IO operations in bits.
> + valid values are 8, 16, and 32. If this property is not specified, or has
> + an invalid value, the driver will default to 32 bits.
Minor nit, but rightly or wrongly, the of-serial binding that uses
reg-io-width specifies this in bytes and it would be nice to be
consistent here.
Jamie
^ permalink raw reply
* Re: Move interface across network namespaces
From: Renato Westphal @ 2011-08-15 13:10 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, kaber, David Lamparter
In-Reply-To: <CAChaegm2d3LywMAcq66PgPZwF5Fu=_zuqcTh8VdCG6zvhyPJXQ@mail.gmail.com>
2011/8/11 Renato Westphal <renatowestphal@gmail.com>:
> 2011/8/11 Eric W. Biederman <ebiederm@xmission.com>:
>> Renato Westphal <renatowestphal@gmail.com> writes:
>>
>>> Hello,
>>>
>>> I have two questions regarding the process of moving a network
>>> interface across different network namespaces:
>>>
>>> * When I move an interface, all the virtual interfaces attached to it
>>> are deleted. Is there any reason for such odd behavior? I would like
>>> to move some network interfaces and keep the attached vlans untouched.
>>
>> The defined semantics are that a network device is unregistered from
>> the networking stack in one network namespace and then registered
>> with the networking stack in another. It is an unfortunate fact
>> that when vlan devices see their underlying device being unregistered
>> they decide to delete themselves.
>>
>> A different vlan implementation might be able to have different
>> properties but I can't think of any obvious solution other than
>> don't do move the device that you have your vlans on top of.
>>
>
> Thanks for the info, I can handle with that by modifying my quagga-vrf patches.
I forgot to mention that I'm using kernel v2.6.35 (with a lot of
backports). For future reference, the commit 3b27e105550f7c4a ("netns:
keep vlan slaves on master netns move", merged into v2.6.37-rc1) fixes
this problem.
>>> * The target network namespace sends a RTM_NEWLINK netlink message
>>> when an interface is moved to it. In the other hand, the source
>>> network namespace doesn't sends a RTM_DELLINK message when an
>>> interface is moved from it. This is very annoying because user space
>>> applications (such as zebra) can't detect some interface moving
>>> operations and then get into an inconsistent state. Anyone knows if
>>> there's a workaround for this?
>>
>> Not getting RTM_DELLINK is a bug. The device registration and
>> unregistration code has changed since dev_change_net_namespace was
>> written and apparently one of the changes failed to update
>> dev_change_net_namespace.
>>
>
> Good, that makes a lot more sense. In the kernel 2.6.32.43 the
> RTM_DELLINK netlink message is sent when a network interface is moved
> from a network namespace. The same doesn't happens in the kernel
> 2.6.35.13. I'll try to isolate the problem some more.
Well, this regression was introduced by commit a2835763e130c343ac,
which was merged into v2.6.34. Reverting parts of this commit makes
the problem go away but breaks the support of "specifying device flags
during device creation". I don't know the best way to fix this... any
ideas?
--
Renato Westphal
^ permalink raw reply
* Re: [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Eilon Greenstein @ 2011-08-15 12:33 UTC (permalink / raw)
To: Michal Schmidt
Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <4E490A1E.3060209@redhat.com>
On Mon, 2011-08-15 at 04:59 -0700, Michal Schmidt wrote:
> On 08/15/2011 12:54 PM, Eilon Greenstein wrote:
> > On Fri, 2011-08-12 at 07:33 -0700, Michal Schmidt wrote:
> >> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
> >> index c423504..648e165 100644
> >> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
> >> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
> >> @@ -1220,6 +1220,7 @@ struct bnx2x {
> >> struct cmng_struct_per_port cmng;
> >> u32 vn_weight_sum;
> >> u32 mf_config[E1HVN_MAX];
> >> + bool prev_max_cfg_invalid[E1HVN_MAX];
> > The warning is always for the current VN, so if you insist on showing a
> > warning only once on a board with invalid configuration, you can use a
> > single boolean.
>
> bnx2x_cmng_fns_init() iterates over VNs:
>
> for (vn = VN_0; vn < E1HVN_MAX; vn++)
> bnx2x_init_vn_minmax(bp, vn);
>
> and bnx2x_init_vn_minmax() calls bnx2x_extract_max_cfg() on the given
> VN, so it seems that the warning can be produced for a non-current VN.
You are right, only one function (the PMF) will call this code for all
functions. But I suspect that if you have zero values, you will have
them for all VNs - is that the case? If so, you can still warn only
once. Adding 4 boolean variables to the bnx2x structure just to overcome
a bad configuration seems excessive to me.
^ permalink raw reply
* re commit d4f73c8e459d355e10051174d859ffd0ef5764c0
From: Jiri Pirko @ 2011-08-15 12:12 UTC (permalink / raw)
To: romieu; +Cc: netdev, davem, stephan.baerwolf
Hi Francois.
Looking at mentioned commit, Not sure if the functionality is correct.
Your patch message says:
The non-tagged interface is filtered out as soon as a tagged
(!= 0) interface is created. Its traffic appears again when an
zero-tagged interface is created.
I would presume non-tagged packet would not be filtered any time.
Removing "WORD_REG_BITS_ON(MCFG_RTGOPT, ®s->MCFG);" should probably
do the trick.
Thanks.
Jirka
^ permalink raw reply
* Re: [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Michal Schmidt @ 2011-08-15 11:59 UTC (permalink / raw)
To: eilong; +Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <1313405680.31417.6.camel@lb-tlvb-eilong.il.broadcom.com>
On 08/15/2011 12:54 PM, Eilon Greenstein wrote:
> On Fri, 2011-08-12 at 07:33 -0700, Michal Schmidt wrote:
>> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
>> index c423504..648e165 100644
>> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
>> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
>> @@ -1220,6 +1220,7 @@ struct bnx2x {
>> struct cmng_struct_per_port cmng;
>> u32 vn_weight_sum;
>> u32 mf_config[E1HVN_MAX];
>> + bool prev_max_cfg_invalid[E1HVN_MAX];
> The warning is always for the current VN, so if you insist on showing a
> warning only once on a board with invalid configuration, you can use a
> single boolean.
bnx2x_cmng_fns_init() iterates over VNs:
for (vn = VN_0; vn < E1HVN_MAX; vn++)
bnx2x_init_vn_minmax(bp, vn);
and bnx2x_init_vn_minmax() calls bnx2x_extract_max_cfg() on the given
VN, so it seems that the warning can be produced for a non-current VN.
Michal
^ permalink raw reply
* Congratulations!!! You Are a Certified Winner of Our 2011 Promo
From: Pepsi Bottling Company Plc @ 2011-08-15 11:44 UTC (permalink / raw)
Your email has won £120,000.00 POUNDS from Pepsi online
promotions2011,send your Full names, Age, Sex,Occupation,Phone number and
Address to the Promo Manager, Mrs. Francess Dave Tel: +447011150911
^ permalink raw reply
* Apply for loan today at 3% interest rate
From: Royal Loan Company @ 2011-08-15 11:49 UTC (permalink / raw)
To: Recipients
We are financial builders and gives out no credit check loans to all
ranging from personal,commercial,business,venture,start up,consolidation,
refinance and all form of loans with amounts ranging from $3,500 to $50,000,000.00 with a fixed and very low interest rate of 3% on an annual basis.Apply for loan today at 3% interest rate.send application if intrested to royalloancoplc@w.cn
^ permalink raw reply
* [PATCH] net/can/mscan: add __iomem annotations
From: Marc Kleine-Budde @ 2011-08-15 10:57 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde
This patch fixes the following sparse warning by adding the missing
__iomem annotation.
drivers/net/can/mscan/mscan.c:73:32: warning: incorrect type in argument 1 (different address spaces)
drivers/net/can/mscan/mscan.c:73:32: expected unsigned char volatile [noderef] [usertype] <asn:2>*addr
drivers/net/can/mscan/mscan.c:73:32: got unsigned char *<noident>
Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
This patch applies so current net-next-2.6/master and can be pulled:
The following changes since commit b333293058aa2d401737c7246bce58f8ba00906d:
qeth: add support for af_iucv HiperSockets transport (2011-08-13 01:10:17 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/mkl/linux-2.6.git can/mscan
Marc Kleine-Budde (1):
net/can/mscan: add __iomem annotations
drivers/net/can/mscan/mscan.c | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/can/mscan/mscan.c b/drivers/net/can/mscan/mscan.c
index 92feac6..ac42f5d 100644
--- a/drivers/net/can/mscan/mscan.c
+++ b/drivers/net/can/mscan/mscan.c
@@ -62,7 +62,7 @@ static enum can_state state_map[] = {
static int mscan_set_mode(struct net_device *dev, u8 mode)
{
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
int ret = 0;
int i;
u8 canctl1;
@@ -138,7 +138,7 @@ static int mscan_set_mode(struct net_device *dev, u8 mode)
static int mscan_start(struct net_device *dev)
{
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
u8 canrflg;
int err;
@@ -178,7 +178,7 @@ static int mscan_restart(struct net_device *dev)
struct mscan_priv *priv = netdev_priv(dev);
if (priv->type == MSCAN_TYPE_MPC5121) {
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
priv->can.state = CAN_STATE_ERROR_ACTIVE;
WARN(!(in_8(®s->canmisc) & MSCAN_BOHOLD),
@@ -199,7 +199,7 @@ static netdev_tx_t mscan_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct can_frame *frame = (struct can_frame *)skb->data;
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
int i, rtr, buf_id;
u32 can_id;
@@ -305,7 +305,7 @@ static enum can_state check_set_state(struct net_device *dev, u8 canrflg)
static void mscan_get_rx_frame(struct net_device *dev, struct can_frame *frame)
{
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
u32 can_id;
int i;
@@ -343,7 +343,7 @@ static void mscan_get_err_frame(struct net_device *dev, struct can_frame *frame,
u8 canrflg)
{
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
struct net_device_stats *stats = &dev->stats;
enum can_state old_state;
@@ -406,7 +406,7 @@ static int mscan_rx_poll(struct napi_struct *napi, int quota)
{
struct mscan_priv *priv = container_of(napi, struct mscan_priv, napi);
struct net_device *dev = napi->dev;
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
struct net_device_stats *stats = &dev->stats;
int npackets = 0;
int ret = 1;
@@ -453,7 +453,7 @@ static irqreturn_t mscan_isr(int irq, void *dev_id)
{
struct net_device *dev = (struct net_device *)dev_id;
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
struct net_device_stats *stats = &dev->stats;
u8 cantier, cantflg, canrflg;
irqreturn_t ret = IRQ_NONE;
@@ -537,7 +537,7 @@ static int mscan_do_set_mode(struct net_device *dev, enum can_mode mode)
static int mscan_do_set_bittiming(struct net_device *dev)
{
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
struct can_bittiming *bt = &priv->can.bittiming;
u8 btr0, btr1;
@@ -559,7 +559,7 @@ static int mscan_open(struct net_device *dev)
{
int ret;
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
/* common open */
ret = open_candev(dev);
@@ -598,7 +598,7 @@ exit_napi_disable:
static int mscan_close(struct net_device *dev)
{
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
netif_stop_queue(dev);
napi_disable(&priv->napi);
@@ -622,7 +622,7 @@ static const struct net_device_ops mscan_netdev_ops = {
int register_mscandev(struct net_device *dev, int mscan_clksrc)
{
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
u8 ctl1;
ctl1 = in_8(®s->canctl1);
@@ -659,7 +659,7 @@ int register_mscandev(struct net_device *dev, int mscan_clksrc)
void unregister_mscandev(struct net_device *dev)
{
struct mscan_priv *priv = netdev_priv(dev);
- struct mscan_regs *regs = (struct mscan_regs *)priv->reg_base;
+ struct mscan_regs __iomem *regs = priv->reg_base;
mscan_set_mode(dev, MSCAN_INIT_MODE);
clrbits8(®s->canctl1, MSCAN_CANE);
unregister_candev(dev);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Eilon Greenstein @ 2011-08-15 10:54 UTC (permalink / raw)
To: Michal Schmidt
Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <20110812143324.5740.45824.stgit@dhcp-29-224.brq.redhat.com>
On Fri, 2011-08-12 at 07:33 -0700, Michal Schmidt wrote:
> When a VN is configured with invalid Max BW, the error does not have to
> be logged repeatedly and fill the logs.
> Warn only once when the bad configuration is detected on boot, or when
> the configuration changes dynamically from good to bad.
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> ---
>
> drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 1 +
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 5 ++---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 21 +++++++++++----------
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
> 4 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
> index c423504..648e165 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
> @@ -1220,6 +1220,7 @@ struct bnx2x {
> struct cmng_struct_per_port cmng;
> u32 vn_weight_sum;
> u32 mf_config[E1HVN_MAX];
> + bool prev_max_cfg_invalid[E1HVN_MAX];
The warning is always for the current VN, so if you insist on showing a
warning only once on a board with invalid configuration, you can use a
single boolean.
Thanks,
Eilon
^ permalink raw reply
* [PATCH net-2.6] bonding:restore backup and inactive flag of slave
From: Weiping Pan @ 2011-08-15 10:25 UTC (permalink / raw)
To: netdev; +Cc: Weiping Pan
In-Reply-To: <CANMAZFWYUqDDp+_9EOOubRcvC90zHO9NR7D_N5D=uTjokpgU6A@mail.gmail.com>
Eduard Sinelnikov (eduard.sinelnikov@gmail.com) found that if we change
bonding mode from active backup to round robin, some slaves are still keeping
"backup", and won't transmit packets.
As Jay Vosburgh(fubar@us.ibm.com) pointed out that we can work around that by
removing the bond_is_active_slave() check, because the "backup" flag is only
meaningful for active backup mode.
But if we just simply ignore the bond_is_active_slave() check,
the transmission will work fine, but we can't maintain the correct value of
"backup" flag for each slaves, though it is meaningless for other mode than
active backup.
I'd like to restore "backup" and "inactive" flag in bond_open,
thus we can keep the correct value of them.
As for bond_is_active_slave(), I'd like to prepare another patch to handle it.
Signed-off-by: Weiping Pan <panweiping3@gmail.com>
---
drivers/net/bonding/bond_main.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 38a83ac..3ed9827 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3419,9 +3419,27 @@ static int bond_xmit_hash_policy_l2(struct sk_buff *skb, int count)
static int bond_open(struct net_device *bond_dev)
{
struct bonding *bond = netdev_priv(bond_dev);
+ struct slave *slave;
+ int i;
bond->kill_timers = 0;
+ // restore slave->backup and slave->inactive
+ read_lock(&bond->lock);
+ read_lock(&bond->curr_slave_lock);
+ if (bond->slave_cnt > 0) {
+ bond_for_each_slave(bond, slave, i) {
+ if ((bond->params.mode == BOND_MODE_ACTIVEBACKUP)
+ && (slave != bond->curr_active_slave)) {
+ bond_set_slave_inactive_flags(slave);
+ } else {
+ bond_set_slave_active_flags(slave);
+ }
+ }
+ }
+ read_unlock(&bond->curr_slave_lock);
+ read_unlock(&bond->lock);
+
INIT_DELAYED_WORK(&bond->mcast_work, bond_resend_igmp_join_requests_delayed);
if (bond_is_lb(bond)) {
--
1.7.4.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox