* Re: [PATCH] net: configurable sysctl parameter "net.core.tcp_lowat" for sk_stream_min_wspace()
From: David Miller @ 2011-08-15 5:47 UTC (permalink / raw)
To: jun.kondo
Cc: linux-kernel, omega-g1, notsuki, motokazu.kozaki, htaira, netdev,
tomohiko.takahashi, kotaro.sakai, ken.sugawara
In-Reply-To: <4E48B0C3.2010203@ctc-g.co.jp>
From: "Jun.Kondo" <jun.kondo@ctc-g.co.jp>
Date: Mon, 15 Aug 2011 14:38:11 +0900
> 2. to limit the block time of the write in order to
> prevent the timeout of upper layer applications
> even when the connection has low throughput, such
> as low rate streaming
Use non-blocking writes if you want this behavior.
^ permalink raw reply
* Re: ip_rt_bug: 10.0.0.52 -> 255.255.255.255, ?
From: Justin P. Mattock @ 2011-08-15 5:55 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <20110814.224536.1330937123770047026.davem@davemloft.net>
Oh.. guess I will wait for those to be put into the Mainline then.
Thanks for the info!
>
> First, please contact netdev@vger.kernel.org for networking issues.
>
> Second, this is fixed already:
>
> commit d547f727df86059104af2234804fdd538e112015
> Author: Julian Anastasov<ja@ssi.bg>
> Date: Sun Aug 7 22:20:20 2011 -0700
>
> ipv4: fix the reusing of routing cache entries
>
> compare_keys and ip_route_input_common rely on
> rt_oif for distinguishing of input and output routes
> with same keys values. But sometimes the input route has
> also same hash chain (keyed by iif != 0) with the output
> routes (keyed by orig_oif=0). Problem visible if running
> with small number of rhash_entries.
>
> Fix them to use rt_route_iif instead. By this way
> input route can not be returned to users that request
> output route.
>
> The patch fixes the ip_rt_bug errors that were
> reported in ip_local_out context, mostly for 255.255.255.255
> destinations.
>
> Signed-off-by: Julian Anastasov<ja@ssi.bg>
> Signed-off-by: David S. Miller<davem@davemloft.net>
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index e3dec1c..cb7efe0 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -731,6 +731,7 @@ static inline int compare_keys(struct rtable *rt1, struct rtable *rt2)
> ((__force u32)rt1->rt_key_src ^ (__force u32)rt2->rt_key_src) |
> (rt1->rt_mark ^ rt2->rt_mark) |
> (rt1->rt_key_tos ^ rt2->rt_key_tos) |
> + (rt1->rt_route_iif ^ rt2->rt_route_iif) |
> (rt1->rt_oif ^ rt2->rt_oif) |
> (rt1->rt_iif ^ rt2->rt_iif)) == 0;
> }
> @@ -2321,8 +2322,8 @@ int ip_route_input_common(struct sk_buff *skb, __be32 daddr, __be32 saddr,
> if ((((__force u32)rth->rt_key_dst ^ (__force u32)daddr) |
> ((__force u32)rth->rt_key_src ^ (__force u32)saddr) |
> (rth->rt_iif ^ iif) |
> - rth->rt_oif |
> (rth->rt_key_tos ^ tos)) == 0&&
> + rt_is_input_route(rth)&&
> rth->rt_mark == skb->mark&&
> net_eq(dev_net(rth->dst.dev), net)&&
> !rt_is_expired(rth)) {
>
>
>
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: David Miller @ 2011-08-15 5:56 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110815152048.3b8f8484faf1891ef2fce266@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 15 Aug 2011 15:20:48 +1000
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> make[5]: *** No rule to make target `drivers/net/ethernet/toshiba/ethernet/sun/sungem_phy.o', needed by `drivers/net/ethernet/toshiba/built-in.o'.
> In file included from drivers/net/ethernet/toshiba/spider_net_ethtool.c:28:0:
> drivers/net/ethernet/toshiba/spider_net.h:30:39: fatal error: ./ethernet/sun/sungem_phy.h: No such file or directory
> In file included from drivers/net/ethernet/toshiba/spider_net.c:54:0:
> drivers/net/ethernet/toshiba/spider_net.h:30:39: fatal error: ./ethernet/sun/sungem_phy.h: No such file or directory
>
> Caused by commit 8df158ac36fa ("toshiba: Move the Toshiba drivers") or
> the surrounding commits.
>
> I have just left this failure for today.
This should fix the include problem, but I suspect this thing won't
link.
Jeff we have to resolve this somehow, I explained last week how
you can't include object files outside of the current directory
in constructs like is being done for the spider_net driver in
order to get the sungem_phy.o thing tacked on.
--------------------
>From 2bb698412d8aab0bfc3f269f5ebe8eb67d7cc8f4 Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Sun, 14 Aug 2011 22:52:04 -0700
Subject: [PATCH] net: Move sungem_phy.h under include/linux
Fixes build failures of the spider_net driver because it tries
to use a convoluted path to include this header.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/sun/sungem.c | 2 +-
drivers/net/ethernet/sun/sungem_phy.h | 132 -----------------------------
drivers/net/ethernet/toshiba/spider_net.h | 2 +-
include/linux/sungem_phy.h | 132 +++++++++++++++++++++++++++++
4 files changed, 134 insertions(+), 134 deletions(-)
delete mode 100644 drivers/net/ethernet/sun/sungem_phy.h
create mode 100644 include/linux/sungem_phy.h
diff --git a/drivers/net/ethernet/sun/sungem.c b/drivers/net/ethernet/sun/sungem.c
index ade35dd..0f13c5d 100644
--- a/drivers/net/ethernet/sun/sungem.c
+++ b/drivers/net/ethernet/sun/sungem.c
@@ -59,7 +59,7 @@
#include <asm/pmac_feature.h>
#endif
-#include "sungem_phy.h"
+#include <linux/sungem_phy.h>
#include "sungem.h"
/* Stripping FCS is causing problems, disabled for now */
diff --git a/drivers/net/ethernet/sun/sungem_phy.h b/drivers/net/ethernet/sun/sungem_phy.h
deleted file mode 100644
index af02f94..0000000
--- a/drivers/net/ethernet/sun/sungem_phy.h
+++ /dev/null
@@ -1,132 +0,0 @@
-#ifndef __SUNGEM_PHY_H__
-#define __SUNGEM_PHY_H__
-
-struct mii_phy;
-
-/* Operations supported by any kind of PHY */
-struct mii_phy_ops
-{
- int (*init)(struct mii_phy *phy);
- int (*suspend)(struct mii_phy *phy);
- int (*setup_aneg)(struct mii_phy *phy, u32 advertise);
- int (*setup_forced)(struct mii_phy *phy, int speed, int fd);
- int (*poll_link)(struct mii_phy *phy);
- int (*read_link)(struct mii_phy *phy);
- int (*enable_fiber)(struct mii_phy *phy, int autoneg);
-};
-
-/* Structure used to statically define an mii/gii based PHY */
-struct mii_phy_def
-{
- u32 phy_id; /* Concatenated ID1 << 16 | ID2 */
- u32 phy_id_mask; /* Significant bits */
- u32 features; /* Ethtool SUPPORTED_* defines */
- int magic_aneg; /* Autoneg does all speed test for us */
- const char* name;
- const struct mii_phy_ops* ops;
-};
-
-enum {
- BCM54XX_COPPER,
- BCM54XX_FIBER,
- BCM54XX_GBIC,
- BCM54XX_SGMII,
- BCM54XX_UNKNOWN,
-};
-
-/* An instance of a PHY, partially borrowed from mii_if_info */
-struct mii_phy
-{
- struct mii_phy_def* def;
- u32 advertising;
- int mii_id;
-
- /* 1: autoneg enabled, 0: disabled */
- int autoneg;
-
- /* forced speed & duplex (no autoneg)
- * partner speed & duplex & pause (autoneg)
- */
- int speed;
- int duplex;
- int pause;
-
- /* Provided by host chip */
- struct net_device *dev;
- int (*mdio_read) (struct net_device *dev, int mii_id, int reg);
- void (*mdio_write) (struct net_device *dev, int mii_id, int reg, int val);
- void *platform_data;
-};
-
-/* Pass in a struct mii_phy with dev, mdio_read and mdio_write
- * filled, the remaining fields will be filled on return
- */
-extern int mii_phy_probe(struct mii_phy *phy, int mii_id);
-
-
-/* MII definitions missing from mii.h */
-
-#define BMCR_SPD2 0x0040 /* Gigabit enable (bcm54xx) */
-#define LPA_PAUSE 0x0400
-
-/* More PHY registers (model specific) */
-
-/* MII BCM5201 MULTIPHY interrupt register */
-#define MII_BCM5201_INTERRUPT 0x1A
-#define MII_BCM5201_INTERRUPT_INTENABLE 0x4000
-
-#define MII_BCM5201_AUXMODE2 0x1B
-#define MII_BCM5201_AUXMODE2_LOWPOWER 0x0008
-
-#define MII_BCM5201_MULTIPHY 0x1E
-
-/* MII BCM5201 MULTIPHY register bits */
-#define MII_BCM5201_MULTIPHY_SERIALMODE 0x0002
-#define MII_BCM5201_MULTIPHY_SUPERISOLATE 0x0008
-
-/* MII BCM5221 Additional registers */
-#define MII_BCM5221_TEST 0x1f
-#define MII_BCM5221_TEST_ENABLE_SHADOWS 0x0080
-#define MII_BCM5221_SHDOW_AUX_STAT2 0x1b
-#define MII_BCM5221_SHDOW_AUX_STAT2_APD 0x0020
-#define MII_BCM5221_SHDOW_AUX_MODE4 0x1a
-#define MII_BCM5221_SHDOW_AUX_MODE4_IDDQMODE 0x0001
-#define MII_BCM5221_SHDOW_AUX_MODE4_CLKLOPWR 0x0004
-
-/* MII BCM5241 Additional registers */
-#define MII_BCM5241_SHDOW_AUX_MODE4_STANDBYPWR 0x0008
-
-/* MII BCM5400 1000-BASET Control register */
-#define MII_BCM5400_GB_CONTROL 0x09
-#define MII_BCM5400_GB_CONTROL_FULLDUPLEXCAP 0x0200
-
-/* MII BCM5400 AUXCONTROL register */
-#define MII_BCM5400_AUXCONTROL 0x18
-#define MII_BCM5400_AUXCONTROL_PWR10BASET 0x0004
-
-/* MII BCM5400 AUXSTATUS register */
-#define MII_BCM5400_AUXSTATUS 0x19
-#define MII_BCM5400_AUXSTATUS_LINKMODE_MASK 0x0700
-#define MII_BCM5400_AUXSTATUS_LINKMODE_SHIFT 8
-
-/* 1000BT control (Marvell & BCM54xx at least) */
-#define MII_1000BASETCONTROL 0x09
-#define MII_1000BASETCONTROL_FULLDUPLEXCAP 0x0200
-#define MII_1000BASETCONTROL_HALFDUPLEXCAP 0x0100
-
-/* Marvell 88E1011 PHY control */
-#define MII_M1011_PHY_SPEC_CONTROL 0x10
-#define MII_M1011_PHY_SPEC_CONTROL_MANUAL_MDIX 0x20
-#define MII_M1011_PHY_SPEC_CONTROL_AUTO_MDIX 0x40
-
-/* Marvell 88E1011 PHY status */
-#define MII_M1011_PHY_SPEC_STATUS 0x11
-#define MII_M1011_PHY_SPEC_STATUS_1000 0x8000
-#define MII_M1011_PHY_SPEC_STATUS_100 0x4000
-#define MII_M1011_PHY_SPEC_STATUS_SPD_MASK 0xc000
-#define MII_M1011_PHY_SPEC_STATUS_FULLDUPLEX 0x2000
-#define MII_M1011_PHY_SPEC_STATUS_RESOLVED 0x0800
-#define MII_M1011_PHY_SPEC_STATUS_TX_PAUSE 0x0008
-#define MII_M1011_PHY_SPEC_STATUS_RX_PAUSE 0x0004
-
-#endif /* __SUNGEM_PHY_H__ */
diff --git a/drivers/net/ethernet/toshiba/spider_net.h b/drivers/net/ethernet/toshiba/spider_net.h
index a891ad0..4ba2135 100644
--- a/drivers/net/ethernet/toshiba/spider_net.h
+++ b/drivers/net/ethernet/toshiba/spider_net.h
@@ -27,7 +27,7 @@
#define VERSION "2.0 B"
-#include "./ethernet/sun/sungem_phy.h"
+#include <linux/sungem_phy.h>
extern int spider_net_stop(struct net_device *netdev);
extern int spider_net_open(struct net_device *netdev);
diff --git a/include/linux/sungem_phy.h b/include/linux/sungem_phy.h
new file mode 100644
index 0000000..af02f94
--- /dev/null
+++ b/include/linux/sungem_phy.h
@@ -0,0 +1,132 @@
+#ifndef __SUNGEM_PHY_H__
+#define __SUNGEM_PHY_H__
+
+struct mii_phy;
+
+/* Operations supported by any kind of PHY */
+struct mii_phy_ops
+{
+ int (*init)(struct mii_phy *phy);
+ int (*suspend)(struct mii_phy *phy);
+ int (*setup_aneg)(struct mii_phy *phy, u32 advertise);
+ int (*setup_forced)(struct mii_phy *phy, int speed, int fd);
+ int (*poll_link)(struct mii_phy *phy);
+ int (*read_link)(struct mii_phy *phy);
+ int (*enable_fiber)(struct mii_phy *phy, int autoneg);
+};
+
+/* Structure used to statically define an mii/gii based PHY */
+struct mii_phy_def
+{
+ u32 phy_id; /* Concatenated ID1 << 16 | ID2 */
+ u32 phy_id_mask; /* Significant bits */
+ u32 features; /* Ethtool SUPPORTED_* defines */
+ int magic_aneg; /* Autoneg does all speed test for us */
+ const char* name;
+ const struct mii_phy_ops* ops;
+};
+
+enum {
+ BCM54XX_COPPER,
+ BCM54XX_FIBER,
+ BCM54XX_GBIC,
+ BCM54XX_SGMII,
+ BCM54XX_UNKNOWN,
+};
+
+/* An instance of a PHY, partially borrowed from mii_if_info */
+struct mii_phy
+{
+ struct mii_phy_def* def;
+ u32 advertising;
+ int mii_id;
+
+ /* 1: autoneg enabled, 0: disabled */
+ int autoneg;
+
+ /* forced speed & duplex (no autoneg)
+ * partner speed & duplex & pause (autoneg)
+ */
+ int speed;
+ int duplex;
+ int pause;
+
+ /* Provided by host chip */
+ struct net_device *dev;
+ int (*mdio_read) (struct net_device *dev, int mii_id, int reg);
+ void (*mdio_write) (struct net_device *dev, int mii_id, int reg, int val);
+ void *platform_data;
+};
+
+/* Pass in a struct mii_phy with dev, mdio_read and mdio_write
+ * filled, the remaining fields will be filled on return
+ */
+extern int mii_phy_probe(struct mii_phy *phy, int mii_id);
+
+
+/* MII definitions missing from mii.h */
+
+#define BMCR_SPD2 0x0040 /* Gigabit enable (bcm54xx) */
+#define LPA_PAUSE 0x0400
+
+/* More PHY registers (model specific) */
+
+/* MII BCM5201 MULTIPHY interrupt register */
+#define MII_BCM5201_INTERRUPT 0x1A
+#define MII_BCM5201_INTERRUPT_INTENABLE 0x4000
+
+#define MII_BCM5201_AUXMODE2 0x1B
+#define MII_BCM5201_AUXMODE2_LOWPOWER 0x0008
+
+#define MII_BCM5201_MULTIPHY 0x1E
+
+/* MII BCM5201 MULTIPHY register bits */
+#define MII_BCM5201_MULTIPHY_SERIALMODE 0x0002
+#define MII_BCM5201_MULTIPHY_SUPERISOLATE 0x0008
+
+/* MII BCM5221 Additional registers */
+#define MII_BCM5221_TEST 0x1f
+#define MII_BCM5221_TEST_ENABLE_SHADOWS 0x0080
+#define MII_BCM5221_SHDOW_AUX_STAT2 0x1b
+#define MII_BCM5221_SHDOW_AUX_STAT2_APD 0x0020
+#define MII_BCM5221_SHDOW_AUX_MODE4 0x1a
+#define MII_BCM5221_SHDOW_AUX_MODE4_IDDQMODE 0x0001
+#define MII_BCM5221_SHDOW_AUX_MODE4_CLKLOPWR 0x0004
+
+/* MII BCM5241 Additional registers */
+#define MII_BCM5241_SHDOW_AUX_MODE4_STANDBYPWR 0x0008
+
+/* MII BCM5400 1000-BASET Control register */
+#define MII_BCM5400_GB_CONTROL 0x09
+#define MII_BCM5400_GB_CONTROL_FULLDUPLEXCAP 0x0200
+
+/* MII BCM5400 AUXCONTROL register */
+#define MII_BCM5400_AUXCONTROL 0x18
+#define MII_BCM5400_AUXCONTROL_PWR10BASET 0x0004
+
+/* MII BCM5400 AUXSTATUS register */
+#define MII_BCM5400_AUXSTATUS 0x19
+#define MII_BCM5400_AUXSTATUS_LINKMODE_MASK 0x0700
+#define MII_BCM5400_AUXSTATUS_LINKMODE_SHIFT 8
+
+/* 1000BT control (Marvell & BCM54xx at least) */
+#define MII_1000BASETCONTROL 0x09
+#define MII_1000BASETCONTROL_FULLDUPLEXCAP 0x0200
+#define MII_1000BASETCONTROL_HALFDUPLEXCAP 0x0100
+
+/* Marvell 88E1011 PHY control */
+#define MII_M1011_PHY_SPEC_CONTROL 0x10
+#define MII_M1011_PHY_SPEC_CONTROL_MANUAL_MDIX 0x20
+#define MII_M1011_PHY_SPEC_CONTROL_AUTO_MDIX 0x40
+
+/* Marvell 88E1011 PHY status */
+#define MII_M1011_PHY_SPEC_STATUS 0x11
+#define MII_M1011_PHY_SPEC_STATUS_1000 0x8000
+#define MII_M1011_PHY_SPEC_STATUS_100 0x4000
+#define MII_M1011_PHY_SPEC_STATUS_SPD_MASK 0xc000
+#define MII_M1011_PHY_SPEC_STATUS_FULLDUPLEX 0x2000
+#define MII_M1011_PHY_SPEC_STATUS_RESOLVED 0x0800
+#define MII_M1011_PHY_SPEC_STATUS_TX_PAUSE 0x0008
+#define MII_M1011_PHY_SPEC_STATUS_RX_PAUSE 0x0004
+
+#endif /* __SUNGEM_PHY_H__ */
--
1.7.6
^ permalink raw reply related
* Re: ip_rt_bug: 10.0.0.52 -> 255.255.255.255, ?
From: David Miller @ 2011-08-15 5:56 UTC (permalink / raw)
To: justinmattock; +Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <4E48B4B6.8000603@gmail.com>
From: "Justin P. Mattock" <justinmattock@gmail.com>
Date: Sun, 14 Aug 2011 22:55:02 -0700
> Oh.. guess I will wait for those to be put into the Mainline
> then. Thanks for the info!
It is in mainline.
^ permalink raw reply
* Re: [net-next 03/12] ethoc: Move the Avionic driver
From: Thierry Reding @ 2011-08-15 6:06 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann
In-Reply-To: <1313222196-10074-4-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 318 bytes --]
* Jeff Kirsher wrote:
> Move the Avionic driver into drivers/net/ethernet/ and make the
> necessary Kconfig and Makefile changes.
>
> CC: Thierry Reding <thierry.reding@avionic-design.de>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: ip_rt_bug: 10.0.0.52 -> 255.255.255.255, ?
From: Justin P. Mattock @ 2011-08-15 6:09 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <20110814.225633.1354751384914126321.davem@davemloft.net>
On 08/14/2011 10:56 PM, David Miller wrote:
> From: "Justin P. Mattock"<justinmattock@gmail.com>
> Date: Sun, 14 Aug 2011 22:55:02 -0700
>
>> Oh.. guess I will wait for those to be put into the Mainline
>> then. Thanks for the info!
>
> It is in mainline.
>
alright.. I see it now. I pulled on thurs/fri but never went any further
with the build after that. will clean and build when I get a chance and
run it.
Thanks again!
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH] tcp: Use LIMIT_NETDEBUG in syn_flood_warning()
From: David Miller @ 2011-08-15 6:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, netdev
In-Reply-To: <1313129310.2669.19.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 12 Aug 2011 08:08:30 +0200
> [PATCH] tcp: Use LIMIT_NETDEBUG in syn_flood_warning()
>
> LIMIT_NETDEBUG allows the admin to disable some warning messages :
> echo 0 > /proc/sys/net/core/warnings
>
> Use it to avoid filling syslog on busy servers.
>
> Based on a previous patch from Tom Herbert
>
> Factorize syn_flood_warning() IPv4/IPv6 implementations
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Tom Herbert <therbert@google.com>
This is a big hammer with no granularity.
I have to give up other potentially interesting log messages (open
request drops, IP frag out-of-memory, etc.) just to get this one to go
away.
I still stand by my original suggestion, print unconditionally and
only once, and also add the statistics counters.
^ permalink raw reply
* Bonding problem
From: Eduard Sinelnikov @ 2011-08-15 9:44 UTC (permalink / raw)
To: netdev, Andy Gospodarek, Jay Vosburgh
[-- Attachment #1: Type: text/plain, Size: 3853 bytes --]
Hi all,
Following the thread:
http://marc.info/?l=linux-netdev&m=131282467512508&w=2
I have created the this patch for kernel version:3.0.1, which may fix
the bonding problem
Patch explanation:
The patch seting all slaves active prior to switching to round robin mode.
This is done to ensure that every posibly active slave will be used in
communication.
Also, I noticed that just changing the bond_xmit_round_robin will only
partially fix the problem.
Since slaves with inactive bit will not CATCH any trafic.
I wonder if I should remove the check "bond_is_active_slave(slave))"
in bond_xmit_round_robin
Please advice.
Eduard
On Mon, Aug 08, 2011 at 10:06:05AM -0700, Jay Vosburgh wrote:
>
> Andy Gospodarek <andy@greyhouse.net> wrote:
>
> >On Sun, Aug 07, 2011 at 03:00:30PM +0300, Eduard Sinelnikov wrote:
> >> Hi,
> >>
> >> In the kernel 2.6.39.3 ( /drivers/net/bond/bond_main.c).
> >> In the function  ‘bond_xmit_roundrobin’
> >> The code check if the bond is active via
> >> ‘bond_is_active_slave(slave)’ Function call.
> >> Which actually checks if the slave is backup or active
> >> What is the meaning of slave being  backup in round robin mode?
> >> Correct me if I wrong but in round robin every slave should send a
> >> packet, regardless of being active or backup.
> >>
> >> Thank you,
> >> Â Â Â Â Â Â Eduard
> >
> >There probably is not a compelling reason to continue to have it. There
> >may be a reason historically, but I'm not aware what that might be at
> >this point. For modes other than active-backup, the value of
> >slave->link and slave->backup should always contain a value that
> >indicates the slave is up and available for transmit.
>
> If you read Eduard's other posts regarding this, the actual
> issue is that when changing from another mode into round-robin,
> occasionally slaves will still be marked as "backup" and won't be used:
>
I did notice that one after I sent this first response.
> >Date: Mon, 8 Aug 2011 11:16:39 +0300
> >Subject: On line Bonding configuration change fails
> >From: Eduard Sinelnikov <eduard.sinelnikov@gmail.com>
> >To: netdev@vger.kernel.org
> >Sender: netdev-owner@vger.kernel.org
> >
> >Hi,
> >
> >My configuration is a follows:
> >
> >Â Â Â Â Â Â Â | eth0 -------------->
> >Ububntu | eth1 --------------> Â Â Swith ------------> Other computer
> >
> >Scenario:
> >• change the bond mode to active/backup
> >• unplug some of the cable
> >• plug-in the unplugged cable
> >• change bond mode to round robin
> >
> >I can see that only one eth1 is sending data. When I unplug it the ping stops.
> >
> >Is it a bug or some mis-configuration?
> >
> >In the kernel ( /drivers/net/bond/bond_main.c).
> >In the function  ‘bond_xmit_roundrobin
> >’
> >The code check if the bond is active via
> >‘bond_is_active_slave(slave)’ Function call.
> >Which actually checks if the slave is backup or active
> >What is the meaning of backup in round robin?
> >Correct me if I wrong but in round robin every slave should send a
> >packet, regardless of being active or backup.
>
> So from looking at the code, it seems that the actual problem is
> that when transitioning to round-robin mode, one or more slaves can
> remain marked as "backup," and in round-robin mode, that won't ever
> change. We could probably work around that by removing the "is_active"
> test (essentially declaring that "is_active" is only valid in
> active-backup mode). That might produce a few odd messages here and
> there (when removing a slave or during a link failure, for example).
>
> From inspection, the bond_xmit_xor function likely has this same
> problem.
>
Agreed.
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
[-- Attachment #2: bond_patch.patch --]
[-- Type: application/octet-stream, Size: 1471 bytes --]
diff -uprN linux-3.0.1/drivers/net/bonding/bond_sysfs.c linux-3.0.1.bond/drivers/net/bonding/bond_sysfs.c
--- linux-3.0.1/drivers/net/bonding/bond_sysfs.c 2011-08-05 07:59:21.000000000 +0300
+++ linux-3.0.1.bond/drivers/net/bonding/bond_sysfs.c 2011-08-15 11:59:13.346377263 +0300
@@ -290,6 +290,37 @@ static ssize_t bonding_show_mode(struct
bond->params.mode);
}
+
+
+// activate all interfaces.
+static void inline bonding_activate_interfaces(struct bonding * bond )
+{
+ struct slave *slave ;
+ int i ;
+
+
+
+ read_lock(&bond->lock);
+
+ bond_for_each_slave(bond, slave, i) {
+
+ read_lock(&bond->curr_slave_lock);
+
+ // change the backup to active since there is no meaninng of backup in round robin.
+ // Also, change the device state so it can catch traffic.
+ if (( bond_slave_state(slave) ) || slave->inactive ) {
+ if ((slave->link == BOND_LINK_UP) && IS_UP(slave->dev)) {
+ bond_set_slave_active_flags(slave);
+ }
+ }
+
+ read_unlock(&bond->curr_slave_lock);
+ }
+
+ read_unlock(&bond->lock);
+
+}
+
static ssize_t bonding_store_mode(struct device *d,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -320,6 +351,10 @@ static ssize_t bonding_store_mode(struct
goto out;
}
+ if (bond->params.mode == BOND_MODE_ROUNDROBIN) {
+ bonding_activate_interfaces(bond) ;
+ }
+
bond->params.mode = new_value;
bond_set_mode_ops(bond, bond->params.mode);
pr_info("%s: setting mode to %s (%d).\n",
^ permalink raw reply
* Re: Bonding problem
From: WeipingPan @ 2011-08-15 10:22 UTC (permalink / raw)
To: Eduard Sinelnikov; +Cc: netdev, Andy Gospodarek, Jay Vosburgh
In-Reply-To: <CANMAZFWYUqDDp+_9EOOubRcvC90zHO9NR7D_N5D=uTjokpgU6A@mail.gmail.com>
On 08/15/2011 05:44 PM, Eduard Sinelnikov wrote:
> Hi all,
>
> Following the thread:
> http://marc.info/?l=linux-netdev&m=131282467512508&w=2
>
> I have created the this patch for kernel version:3.0.1, which may fix
> the bonding problem
>
> Patch explanation:
> The patch seting all slaves active prior to switching to round robin mode.
> This is done to ensure that every posibly active slave will be used in
> communication.
>
> Also, I noticed that just changing the bond_xmit_round_robin will only
> partially fix the problem.
> Since slaves with inactive bit will not CATCH any trafic.
>
> I wonder if I should remove the check "bond_is_active_slave(slave))"
> in bond_xmit_round_robin
>
> Please advice.
> Eduard
>
>
My patch is to restore the backup and inactive flag of slave, too,
and I think it is more generic. :-)
Will send it soon.
thanks
Weiping Pan
> On Mon, Aug 08, 2011 at 10:06:05AM -0700, Jay Vosburgh wrote:
>> Andy Gospodarek<andy@greyhouse.net> wrote:
>>
>>> On Sun, Aug 07, 2011 at 03:00:30PM +0300, Eduard Sinelnikov wrote:
>>>> Hi,
>>>>
>>>> In the kernel 2.6.39.3 ( /drivers/net/bond/bond_main.c).
>>>> In the function  ‘bond_xmit_roundrobin’
>>>> The code check if the bond is active via
>>>> ‘bond_is_active_slave(slave)’ Function call.
>>>> Which actually checks if the slave is backup or active
>>>> What is the meaning of slave being  backup in round robin mode?
>>>> Correct me if I wrong but in round robin every slave should send a
>>>> packet, regardless of being active or backup.
>>>>
>>>> Thank you,
>>>> Â Â Â Â Â Â Eduard
>>> There probably is not a compelling reason to continue to have it. There
>>> may be a reason historically, but I'm not aware what that might be at
>>> this point. For modes other than active-backup, the value of
>>> slave->link and slave->backup should always contain a value that
>>> indicates the slave is up and available for transmit.
>> If you read Eduard's other posts regarding this, the actual
>> issue is that when changing from another mode into round-robin,
>> occasionally slaves will still be marked as "backup" and won't be used:
>>
> I did notice that one after I sent this first response.
>
>>> Date: Mon, 8 Aug 2011 11:16:39 +0300
>>> Subject: On line Bonding configuration change fails
>>> From: Eduard Sinelnikov<eduard.sinelnikov@gmail.com>
>>> To: netdev@vger.kernel.org
>>> Sender: netdev-owner@vger.kernel.org
>>>
>>> Hi,
>>>
>>> My configuration is a follows:
>>>
>>> Â Â Â Â Â Â Â | eth0 -------------->
>>> Ububntu | eth1 --------------> Â Â Swith ------------> Other computer
>>>
>>> Scenario:
>>> • change the bond mode to active/backup
>>> • unplug some of the cable
>>> • plug-in the unplugged cable
>>> • change bond mode to round robin
>>>
>>> I can see that only one eth1 is sending data. When I unplug it the ping stops.
>>>
>>> Is it a bug or some mis-configuration?
>>>
>>> In the kernel ( /drivers/net/bond/bond_main.c).
>>> In the function  ‘bond_xmit_roundrobin
>>> ’
>>> The code check if the bond is active via
>>> ‘bond_is_active_slave(slave)’ Function call.
>>> Which actually checks if the slave is backup or active
>>> What is the meaning of backup in round robin?
>>> Correct me if I wrong but in round robin every slave should send a
>>> packet, regardless of being active or backup.
>> So from looking at the code, it seems that the actual problem is
>> that when transitioning to round-robin mode, one or more slaves can
>> remain marked as "backup," and in round-robin mode, that won't ever
>> change. We could probably work around that by removing the "is_active"
>> test (essentially declaring that "is_active" is only valid in
>> active-backup mode). That might produce a few odd messages here and
>> there (when removing a slave or during a link failure, for example).
>>
>> From inspection, the bond_xmit_xor function likely has this same
>> problem.
>>
> Agreed.
>
>> -J
>>
>> ---
>> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ 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
* 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/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
* 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
* 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
* 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
* 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: 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: 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: [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: 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: [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: [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: 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: 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: 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
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