| Message ID | 1469621483-24025-1-git-send-email-abrodkin@synopsys.com |
|---|---|
| State | Changes Requested |
| Delegated to: | John Crispin |
| Headers | show |
On 2016-07-27 14:11, Alexey Brodkin wrote: > For some [still unknown] reason in ARC SDP boards > DW GMAC doesn't enter promiscuous mode if eth0 gets > added to the br-lan interface before Ethernet PHY finishes > autonegotiation (PHY gets reset on DW GMAC start). I think this is something we need to look at more closely instead of just papering over it in this way. By the way, arc* aren't the only ones using stmmac, ipq806x uses it as well and might be equally affected. Did you check if the network stack tells the driver to go into promisc mode? Or does the frame filtering registers simply get clobbered somewhere internally? Let's do some more testing and get this fixed properly... - Felix
Hi Felix, On Wed, 2016-07-27 at 17:19 +0200, Felix Fietkau wrote: > On 2016-07-27 14:11, Alexey Brodkin wrote: > > > > For some [still unknown] reason in ARC SDP boards > > DW GMAC doesn't enter promiscuous mode if eth0 gets > > added to the br-lan interface before Ethernet PHY finishes > > autonegotiation (PHY gets reset on DW GMAC start). > > I think this is something we need to look at more closely instead of > just papering over it in this way. By the way, arc* aren't the only ones > using stmmac, ipq806x uses it as well and might be equally affected. > Did you check if the network stack tells the driver to go into promisc > mode? Or does the frame filtering registers simply get clobbered > somewhere internally? > Let's do some more testing and get this fixed properly... Yeah I know DW GMAC is used a lot around the globe in different forms. For example I have Cubieboard2 where it is used and there I cannot reproduce the same problem. Luckily I have access to GMAC documentation and so I was able to check that Linux driver correctly programs "MAC frame filter" in different situations and still in some cases even if "PR" bit (bit #0) is set CPU doesn't get packages which DST MAC differs from GMAC's one. I.e. it looks like hardware for some reason operates not in the mode it was instructed/programmed to be in. I tried to check if "MAC frame filter" register gets corrupted every time new value was about to be written there but I haven't seen unexpected values. So either that "corruption" happens as a side-effect of some other operations or internal state-machine enters unexpected state based on some external events. If someone may try my reproduction scenario on other boards with DW GMACÂ it might give us more datapoints here. So what I do (before connection of network cable!) is: ------------------>8----------------- ifconfig eth0 up brctl addbr br0 brctl addif br0 eth0 ifconfig br0 up tcpdump -vv -i eth0 -n -e ------------------>8----------------- Then connect network cable and see if tcpdump shows anything. -Alexey
Hi Felix, On Wed, 2016-07-27 at 17:19 +0200, Felix Fietkau wrote: > On 2016-07-27 14:11, Alexey Brodkin wrote: > > > > For some [still unknown] reason in ARC SDP boards > > DW GMAC doesn't enter promiscuous mode if eth0 gets > > added to the br-lan interface before Ethernet PHY finishes > > autonegotiation (PHY gets reset on DW GMAC start). > > I think this is something we need to look at more closely instead of > just papering over it in this way. By the way, arc* aren't the only ones > using stmmac, ipq806x uses it as well and might be equally affected. > Did you check if the network stack tells the driver to go into promisc > mode? Or does the frame filtering registers simply get clobbered > somewhere internally? > > Let's do some more testing and get this fixed properly... So I spent quite some time with that, short summary could be found here: http://lists.infradead.org/pipermail/linux-snps-arc/2016-August/001395.html Probably most important summary for us here is: ------------------------->8-------------------------- Unfortunately I cannot figure out why GMAC behaves that way. As per GMAC's databook the only reason for it to not react on a register being written is missing input clock but there's no reason for the clock to be missing and I don't seem to have a way to check if there's a problem with clock or not. ------------------------->8-------------------------- It worth trying on other boards with DW GMAC but the only other board except ARC SDP ones is Cubieboard2 with sunxi-gmac (which is a kind of DW GMAC as I may see from its Linux's driver) but on CB2 all works as exected. If somebody wants to volunteer I'll be more than happy to work with him/her trying to get more datapoints. And I do think in the meantime it's good to apply this patch so people get working Wireless AP without extra patching of sources or what's even better with snapshot images. -Alexey
Hi Alexey, On Tue, Aug 16, 2016 at 06:06:20AM +0000, Alexey Brodkin wrote: > Hi Felix, > > On Wed, 2016-07-27 at 17:19 +0200, Felix Fietkau wrote: > > On 2016-07-27 14:11, Alexey Brodkin wrote: > > > > > > For some [still unknown] reason in ARC SDP boards > > > DW GMAC doesn't enter promiscuous mode if eth0 gets > > > added to the br-lan interface before Ethernet PHY finishes > > > autonegotiation (PHY gets reset on DW GMAC start). > > > > I think this is something we need to look at more closely instead of > > just papering over it in this way. By the way, arc* aren't the only ones > > using stmmac, ipq806x uses it as well and might be equally affected. > > Did you check if the network stack tells the driver to go into promisc > > mode? Or does the frame filtering registers simply get clobbered > > somewhere internally? > > > > Let's do some more testing and get this fixed properly... > > So I spent quite some time with that, short summary could be found here: > http://lists.infradead.org/pipermail/linux-snps-arc/2016-August/001395.html > > Probably most important summary for us here is: > ------------------------->8-------------------------- > Unfortunately I cannot figure out why GMAC behaves that way. > As per GMAC's databook the only reason for it to not react on a register > being written is missing input clock but there's no reason for the > clock to be missing and I don't seem to have a way to check if there's > a problem with clock or not. > ------------------------->8-------------------------- > > It worth trying on other boards with DW GMAC but the only other board > except ARC SDP ones is Cubieboard2 with sunxi-gmac (which is a kind of > DW GMAC as I may see from its Linux's driver) but on CB2 all works as > exected. If somebody wants to volunteer I'll be more than happy to work > with him/her trying to get more datapoints. stmac/dwmac works as expected on Oxford/PLXTECH OX82x/NAS782x (oxnas target on OpenWrt/LEDE) as well. > > And I do think in the meantime it's good to apply this patch so people > get working Wireless AP without extra patching of sources or what's even > better with snapshot images. > > -Alexey > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev
Hi Daniel, On Tue, 2016-08-16 at 17:12 +0200, Daniel Golle wrote: > Hi Alexey, > > On Tue, Aug 16, 2016 at 06:06:20AM +0000, Alexey Brodkin wrote: > > > > Hi Felix, > > > > On Wed, 2016-07-27 at 17:19 +0200, Felix Fietkau wrote: > > > > > > On 2016-07-27 14:11, Alexey Brodkin wrote: > > > > > > > > > > > > For some [still unknown] reason in ARC SDP boards > > > > DW GMAC doesn't enter promiscuous mode if eth0 gets > > > > added to the br-lan interface before Ethernet PHY finishes > > > > autonegotiation (PHY gets reset on DW GMAC start). > > > > > > I think this is something we need to look at more closely instead of > > > just papering over it in this way. By the way, arc* aren't the only ones > > > using stmmac, ipq806x uses it as well and might be equally affected. > > > Did you check if the network stack tells the driver to go into promisc > > > mode? Or does the frame filtering registers simply get clobbered > > > somewhere internally? > > > > > > Let's do some more testing and get this fixed properly... > > > > So I spent quite some time with that, short summary could be found here: > > http://lists.infradead.org/pipermail/linux-snps-arc/2016-August/001395.html > > > > Probably most important summary for us here is: > > ------------------------->8-------------------------- > > Unfortunately I cannot figure out why GMAC behaves that way. > > As per GMAC's databook the only reason for it to not react on a register > > being written is missing input clock but there's no reason for the > > clock to be missing and I don't seem to have a way to check if there's > > a problem with clock or not. > > ------------------------->8-------------------------- > > > > It worth trying on other boards with DW GMAC but the only other board > > except ARC SDP ones is Cubieboard2 with sunxi-gmac (which is a kind of > > DW GMAC as I may see from its Linux's driver) but on CB2 all works as > > exected. If somebody wants to volunteer I'll be more than happy to work > > with him/her trying to get more datapoints. > > stmac/dwmac works as expected on Oxford/PLXTECH OX82x/NAS782x (oxnas > target on OpenWrt/LEDE) as well. That's good to know but remember what was my use-case to reproduce the problem in questions - DW GMAC must be put in promisq mode while PHY has no link established (the simplest option is to unplug the cable). Have you tried exactly that scenario? -Alexey
diff --git a/target/linux/arc770/patches-4.4/700-stmmac-Disable-fame-filtering-completely.patch b/target/linux/arc770/patches-4.4/700-stmmac-Disable-fame-filtering-completely.patch new file mode 100644 index 0000000..d47f155 --- /dev/null +++ b/target/linux/arc770/patches-4.4/700-stmmac-Disable-fame-filtering-completely.patch @@ -0,0 +1,36 @@ +From 0031b9011cb2b2b1de4dbb4f9620303aec760db4 Mon Sep 17 00:00:00 2001 +From: Alexey Brodkin <abrodkin@synopsys.com> +Date: Wed, 27 Jul 2016 11:33:14 +0300 +Subject: [PATCH] stmmac: Disable fame filtering completely + +For some [still unknown] reason in ARC SDP boards +DW GMAC doesn't enter promiscuous mode if eth0 gets +added to the br-lan interface before Ethernet PHY finishes +autonegotiation (PHY gets reset on DW GMAC start). + +As a work-around we completely disable frame filtering +in GMAC hardware which gives us working bridge that consists +of eth0 and wlan0 (USB Wi-Fi dongle). I.e. we finally have +working "Dumb AP" setup made of ARC AXS10x boards. + +Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> +--- + drivers/net/ethernet/stmicro/stmmac/common.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h +index 623c6ed..6396b81 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/common.h ++++ b/drivers/net/ethernet/stmicro/stmmac/common.h +@@ -42,7 +42,7 @@ + #define DWMAC_CORE_3_50 0x35 + + #undef FRAME_FILTER_DEBUG +-/* #define FRAME_FILTER_DEBUG */ ++#define FRAME_FILTER_DEBUG + + /* Extra statistic and debug information exposed by ethtool */ + struct stmmac_extra_stats { +-- +2.7.4 + diff --git a/target/linux/archs38/patches-4.4/700-stmmac-Disable-fame-filtering-completely.patch b/target/linux/archs38/patches-4.4/700-stmmac-Disable-fame-filtering-completely.patch new file mode 100644 index 0000000..d47f155 --- /dev/null +++ b/target/linux/archs38/patches-4.4/700-stmmac-Disable-fame-filtering-completely.patch @@ -0,0 +1,36 @@ +From 0031b9011cb2b2b1de4dbb4f9620303aec760db4 Mon Sep 17 00:00:00 2001 +From: Alexey Brodkin <abrodkin@synopsys.com> +Date: Wed, 27 Jul 2016 11:33:14 +0300 +Subject: [PATCH] stmmac: Disable fame filtering completely + +For some [still unknown] reason in ARC SDP boards +DW GMAC doesn't enter promiscuous mode if eth0 gets +added to the br-lan interface before Ethernet PHY finishes +autonegotiation (PHY gets reset on DW GMAC start). + +As a work-around we completely disable frame filtering +in GMAC hardware which gives us working bridge that consists +of eth0 and wlan0 (USB Wi-Fi dongle). I.e. we finally have +working "Dumb AP" setup made of ARC AXS10x boards. + +Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> +--- + drivers/net/ethernet/stmicro/stmmac/common.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h +index 623c6ed..6396b81 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/common.h ++++ b/drivers/net/ethernet/stmicro/stmmac/common.h +@@ -42,7 +42,7 @@ + #define DWMAC_CORE_3_50 0x35 + + #undef FRAME_FILTER_DEBUG +-/* #define FRAME_FILTER_DEBUG */ ++#define FRAME_FILTER_DEBUG + + /* Extra statistic and debug information exposed by ethtool */ + struct stmmac_extra_stats { +-- +2.7.4 +
For some [still unknown] reason in ARC SDP boards DW GMAC doesn't enter promiscuous mode if eth0 gets added to the br-lan interface before Ethernet PHY finishes autonegotiation (PHY gets reset on DW GMAC start). As a work-around we completely disable frame filtering in GMAC hardware which gives us working bridge that consists of eth0 and wlan0 (USB Wi-Fi dongle). I.e. we finally have working "Dumb AP" setup made of ARC AXS10x boards. Given this is pretty ugly hack we're applying it only for affected platforms which do require eth0 to enter promiscuous mode to operate in a bridge with wlan0. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> --- ...-stmmac-Disable-fame-filtering-completely.patch | 36 ++++++++++++++++++++++ ...-stmmac-Disable-fame-filtering-completely.patch | 36 ++++++++++++++++++++++ 2 files changed, 72 insertions(+) create mode 100644 target/linux/arc770/patches-4.4/700-stmmac-Disable-fame-filtering-completely.patch create mode 100644 target/linux/archs38/patches-4.4/700-stmmac-Disable-fame-filtering-completely.patch