| Message ID | 20200802175502.451663-2-fabian@blaese.de |
|---|---|
| State | Superseded |
| Headers | show |
diff --git a/build_patches/openwrt/0010-ramips-gsw_mt7621-disable-PORT.patch b/build_patches/openwrt/0010-ramips-gsw_mt7621-disable-PORT.patch new file mode 100644 index 0000000..7e6c540 --- /dev/null +++ b/build_patches/openwrt/0010-ramips-gsw_mt7621-disable-PORT.patch @@ -0,0 +1,58 @@ +From 498f1f4f5df2d077ba524f5735906bb52c12d580 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Petr=20=C5=A0tetiar?= <ynezz@true.cz> +Date: Tue, 11 Feb 2020 11:17:41 +0100 +Subject: [PATCH] ramips: gsw_mt7621: disable PORT 5 MAC RX/TX flow control by + default +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Looking at the current upstream driver implementation, it seems like the +TX/RX flow control is enabled only if the flow control pause option is +resolved from the device/link partner advertisements (or otherwise set). + +On the other hand, our current in-tree driver force enables TX/RX +flow control by default, thus possibly leading to TX timeouts if the +other end sends pause frames (which are not properly handled?): + + WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:320 dev_watchdog+0x1ac/0x324 + NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out + +Disabling the flow control on PORT 5 MAC seems to fix this issues as the +pause frames are then filtered out. While at it, I'm removing the if +condition completely as suggested, since this code is run only on mt7621 +SoC, so there is no need to check for the silicon revisions. + +Ref: https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html +Ref: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/50000/12 +Suggested-by: Felix Fietkau <nbd@nbd.name> +Reported-by: Rosen Penev <rosenp@gmail.com> +Signed-off-by: Petr Štetiar <ynezz@true.cz> +(cherry picked from commit c8f8e59816eca49d776562d2d302bf990a87faf0) +--- + .../drivers/net/ethernet/mediatek/gsw_mt7621.c | 12 +++--------- + 1 file changed, 3 insertions(+), 9 deletions(-) + +diff --git a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c +index 89be23900738..232bcd8cf4ea 100644 +--- a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c ++++ b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c +@@ -98,15 +98,9 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw, struct device_node *np) + mt7530_mdio_w32(gsw, 0x7000, 0x3); + usleep_range(10, 20); + +- if ((rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0xFFFF) == 0x0101) { +- /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */ +- mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR); +- mt7530_mdio_w32(gsw, 0x3600, 0x5e30b); +- } else { +- /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */ +- mtk_switch_w32(gsw, 0x2305e33b, GSW_REG_MAC_P0_MCR); +- mt7530_mdio_w32(gsw, 0x3600, 0x5e33b); +- } ++ /* (GE1, Force 1000M/FD, FC OFF, MAX_RX_LENGTH 1536) */ ++ mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR); ++ mt7530_mdio_w32(gsw, 0x3600, 0x5e30b); + + /* (GE2, Link down) */ + mtk_switch_w32(gsw, 0x8000, GSW_REG_MAC_P1_MCR);
hi ich verstehe nicht wirklich was das tut aber scheint 1 zu 1 ausm OpenWRT kopiert zu sein und da mich der Bug auch immer nervt: Reviewed-by: Christian Dresel <fff@chrisi01.de> Ich geh davon aus du hast es mal grundsätzlich getestet ob nix kaputt geht? Gruß Christian On 02.08.20 19:54, Fabian Bläse wrote: > Currently devices based on mt7621 might freeze due to issues > with the ethernet driver. (see [1]) > > This patch might fix these freezes and will be included in OpenWrt 19.07.4 [2]. > While it is hard to reproduce the issue and this patch is therefore not verified > to fix the issue, it is backported into our firmware anyway. > > This patch can be removed when upgrading to OpenWrt 19.07.4. > > [1] https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573 > [2] https://github.com/openwrt/openwrt/commit/c8f8e59816eca49d776562d2d302bf990a87faf0 > > Signed-off-by: Fabian Bläse <fabian@blaese.de> > --- > .../0010-ramips-gsw_mt7621-disable-PORT.patch | 58 +++++++++++++++++++ > 1 file changed, 58 insertions(+) > create mode 100644 build_patches/openwrt/0010-ramips-gsw_mt7621-disable-PORT.patch > > diff --git a/build_patches/openwrt/0010-ramips-gsw_mt7621-disable-PORT.patch b/build_patches/openwrt/0010-ramips-gsw_mt7621-disable-PORT.patch > new file mode 100644 > index 0000000..7e6c540 > --- /dev/null > +++ b/build_patches/openwrt/0010-ramips-gsw_mt7621-disable-PORT.patch > @@ -0,0 +1,58 @@ > +From 498f1f4f5df2d077ba524f5735906bb52c12d580 Mon Sep 17 00:00:00 2001 > +From: =?UTF-8?q?Petr=20=C5=A0tetiar?= <ynezz@true.cz> > +Date: Tue, 11 Feb 2020 11:17:41 +0100 > +Subject: [PATCH] ramips: gsw_mt7621: disable PORT 5 MAC RX/TX flow control by > + default > +MIME-Version: 1.0 > +Content-Type: text/plain; charset=UTF-8 > +Content-Transfer-Encoding: 8bit > + > +Looking at the current upstream driver implementation, it seems like the > +TX/RX flow control is enabled only if the flow control pause option is > +resolved from the device/link partner advertisements (or otherwise set). > + > +On the other hand, our current in-tree driver force enables TX/RX > +flow control by default, thus possibly leading to TX timeouts if the > +other end sends pause frames (which are not properly handled?): > + > + WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:320 dev_watchdog+0x1ac/0x324 > + NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out > + > +Disabling the flow control on PORT 5 MAC seems to fix this issues as the > +pause frames are then filtered out. While at it, I'm removing the if > +condition completely as suggested, since this code is run only on mt7621 > +SoC, so there is no need to check for the silicon revisions. > + > +Ref: https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html > +Ref: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/50000/12 > +Suggested-by: Felix Fietkau <nbd@nbd.name> > +Reported-by: Rosen Penev <rosenp@gmail.com> > +Signed-off-by: Petr Štetiar <ynezz@true.cz> > +(cherry picked from commit c8f8e59816eca49d776562d2d302bf990a87faf0) > +--- > + .../drivers/net/ethernet/mediatek/gsw_mt7621.c | 12 +++--------- > + 1 file changed, 3 insertions(+), 9 deletions(-) > + > +diff --git a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c > +index 89be23900738..232bcd8cf4ea 100644 > +--- a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c > ++++ b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c > +@@ -98,15 +98,9 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw, struct device_node *np) > + mt7530_mdio_w32(gsw, 0x7000, 0x3); > + usleep_range(10, 20); > + > +- if ((rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0xFFFF) == 0x0101) { > +- /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */ > +- mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR); > +- mt7530_mdio_w32(gsw, 0x3600, 0x5e30b); > +- } else { > +- /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */ > +- mtk_switch_w32(gsw, 0x2305e33b, GSW_REG_MAC_P0_MCR); > +- mt7530_mdio_w32(gsw, 0x3600, 0x5e33b); > +- } > ++ /* (GE1, Force 1000M/FD, FC OFF, MAX_RX_LENGTH 1536) */ > ++ mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR); > ++ mt7530_mdio_w32(gsw, 0x3600, 0x5e30b); > + > + /* (GE2, Link down) */ > + mtk_switch_w32(gsw, 0x8000, GSW_REG_MAC_P1_MCR); >
Hallo Christian, On 02.08.20 20:30, Christian Dresel wrote: > ich verstehe nicht wirklich was das tut Es deaktiviert Flow Control. Warum auch immer das hilft. > Ich geh davon aus du hast es mal grundsätzlich getestet ob nix kaputt geht? Läuft schon auf diversen ER-X. Dort tauchen nach wie vor immer wieder mal solche timed out Fehler im Kernel Log auf. Zumindest ist bisher aber keiner von denen eingefroren. Gruß Fabian
passt, dann rein damit. Wenn es das ganze nicht schlechter macht, kann es nur besser werden ;) Gruß Christian On 02.08.20 20:32, Fabian Bläse wrote: > Hallo Christian, > > On 02.08.20 20:30, Christian Dresel wrote: >> ich verstehe nicht wirklich was das tut > Es deaktiviert Flow Control. Warum auch immer das hilft. > >> Ich geh davon aus du hast es mal grundsätzlich getestet ob nix kaputt geht? > Läuft schon auf diversen ER-X. Dort tauchen nach wie vor immer wieder mal solche timed out Fehler im Kernel Log auf. > Zumindest ist bisher aber keiner von denen eingefroren. > > Gruß > Fabian >
Hi, > -----Original Message----- > From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf > Of Fabian Bläse > Sent: Sonntag, 2. August 2020 19:55 > To: franken-dev@freifunk.net > Subject: [PATCH] Backport mt7621 ethernet driver fixes to prevent freezes > > Currently devices based on mt7621 might freeze due to issues with the > ethernet driver. (see [1]) > > This patch might fix these freezes and will be included in OpenWrt 19.07.4 > [2]. > While it is hard to reproduce the issue and this patch is therefore not verified > to fix the issue, it is backported into our firmware anyway. > > This patch can be removed when upgrading to OpenWrt 19.07.4. > > [1] https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after- > r11573 > [2] > https://github.com/openwrt/openwrt/commit/c8f8e59816eca49d776562d2d > 302bf990a87faf0 Hier könnte man den tatsächlichen Link vom Backport nehmen, und nicht vom master: https://github.com/openwrt/openwrt/commit/498f1f4f5df2d077ba524f5735906bb52c12d580 Acked-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Grüße Adrian > > Signed-off-by: Fabian Bläse <fabian@blaese.de> > --- > .../0010-ramips-gsw_mt7621-disable-PORT.patch | 58 > +++++++++++++++++++ > 1 file changed, 58 insertions(+) > create mode 100644 build_patches/openwrt/0010-ramips-gsw_mt7621- > disable-PORT.patch > > diff --git a/build_patches/openwrt/0010-ramips-gsw_mt7621-disable- > PORT.patch b/build_patches/openwrt/0010-ramips-gsw_mt7621-disable- > PORT.patch > new file mode 100644 > index 0000000..7e6c540 > --- /dev/null > +++ b/build_patches/openwrt/0010-ramips-gsw_mt7621-disable- > PORT.patch > @@ -0,0 +1,58 @@ > +From 498f1f4f5df2d077ba524f5735906bb52c12d580 Mon Sep 17 00:00:00 > 2001 > +From: =?UTF-8?q?Petr=20=C5=A0tetiar?= <ynezz@true.cz> > +Date: Tue, 11 Feb 2020 11:17:41 +0100 > +Subject: [PATCH] ramips: gsw_mt7621: disable PORT 5 MAC RX/TX flow > +control by default > +MIME-Version: 1.0 > +Content-Type: text/plain; charset=UTF-8 > +Content-Transfer-Encoding: 8bit > + > +Looking at the current upstream driver implementation, it seems like > +the TX/RX flow control is enabled only if the flow control pause option > +is resolved from the device/link partner advertisements (or otherwise set). > + > +On the other hand, our current in-tree driver force enables TX/RX flow > +control by default, thus possibly leading to TX timeouts if the other > +end sends pause frames (which are not properly handled?): > + > + WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:320 > + dev_watchdog+0x1ac/0x324 NETDEV WATCHDOG: eth0 (mtk_soc_eth): > transmit > + queue 0 timed out > + > +Disabling the flow control on PORT 5 MAC seems to fix this issues as > +the pause frames are then filtered out. While at it, I'm removing the > +if condition completely as suggested, since this code is run only on > +mt7621 SoC, so there is no need to check for the silicon revisions. > + > +Ref: > +https://lists.openwrt.org/pipermail/openwrt-devel/2017- > November/009882. > +html > +Ref: > +https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after- > r11573/5 > +0000/12 > +Suggested-by: Felix Fietkau <nbd@nbd.name> > +Reported-by: Rosen Penev <rosenp@gmail.com> > +Signed-off-by: Petr Štetiar <ynezz@true.cz> (cherry picked from commit > +c8f8e59816eca49d776562d2d302bf990a87faf0) > +--- > + .../drivers/net/ethernet/mediatek/gsw_mt7621.c | 12 +++--------- > + 1 file changed, 3 insertions(+), 9 deletions(-) > + > +diff --git > +a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt76 > +21.c > +b/target/linux/ramips/files- > 4.14/drivers/net/ethernet/mediatek/gsw_mt76 > +21.c index 89be23900738..232bcd8cf4ea 100644 > +--- > +a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt76 > +21.c > ++++ b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_ > ++++ mt7621.c > +@@ -98,15 +98,9 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw, > struct device_node *np) > + mt7530_mdio_w32(gsw, 0x7000, 0x3); > + usleep_range(10, 20); > + > +- if ((rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0xFFFF) == 0x0101) { > +- /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */ > +- mtk_switch_w32(gsw, 0x2305e30b, > GSW_REG_MAC_P0_MCR); > +- mt7530_mdio_w32(gsw, 0x3600, 0x5e30b); > +- } else { > +- /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */ > +- mtk_switch_w32(gsw, 0x2305e33b, > GSW_REG_MAC_P0_MCR); > +- mt7530_mdio_w32(gsw, 0x3600, 0x5e33b); > +- } > ++ /* (GE1, Force 1000M/FD, FC OFF, MAX_RX_LENGTH 1536) */ > ++ mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR); > ++ mt7530_mdio_w32(gsw, 0x3600, 0x5e30b); > + > + /* (GE2, Link down) */ > + mtk_switch_w32(gsw, 0x8000, GSW_REG_MAC_P1_MCR); > -- > 2.28.0
Hi, da wir jetzt direkt auf 19.07.4 wechseln können, habe ich den Patch als superseded markiert. Grüße Adrian > -----Original Message----- > From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf > Of Fabian Bläse > Sent: Sonntag, 2. August 2020 19:55 > To: franken-dev@freifunk.net > Subject: [PATCH] Backport mt7621 ethernet driver fixes to prevent freezes > > Currently devices based on mt7621 might freeze due to issues with the > ethernet driver. (see [1]) > > This patch might fix these freezes and will be included in OpenWrt 19.07.4 > [2]. > While it is hard to reproduce the issue and this patch is therefore not verified > to fix the issue, it is backported into our firmware anyway. > > This patch can be removed when upgrading to OpenWrt 19.07.4. > > [1] https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after- > r11573 > [2] > https://github.com/openwrt/openwrt/commit/c8f8e59816eca49d776562d2d > 302bf990a87faf0 > > Signed-off-by: Fabian Bläse <fabian@blaese.de> > --- > .../0010-ramips-gsw_mt7621-disable-PORT.patch | 58 > +++++++++++++++++++ > 1 file changed, 58 insertions(+) > create mode 100644 build_patches/openwrt/0010-ramips-gsw_mt7621- > disable-PORT.patch > > diff --git a/build_patches/openwrt/0010-ramips-gsw_mt7621-disable- > PORT.patch b/build_patches/openwrt/0010-ramips-gsw_mt7621-disable- > PORT.patch > new file mode 100644 > index 0000000..7e6c540 > --- /dev/null > +++ b/build_patches/openwrt/0010-ramips-gsw_mt7621-disable- > PORT.patch > @@ -0,0 +1,58 @@ > +From 498f1f4f5df2d077ba524f5735906bb52c12d580 Mon Sep 17 00:00:00 > 2001 > +From: =?UTF-8?q?Petr=20=C5=A0tetiar?= <ynezz@true.cz> > +Date: Tue, 11 Feb 2020 11:17:41 +0100 > +Subject: [PATCH] ramips: gsw_mt7621: disable PORT 5 MAC RX/TX flow > +control by default > +MIME-Version: 1.0 > +Content-Type: text/plain; charset=UTF-8 > +Content-Transfer-Encoding: 8bit > + > +Looking at the current upstream driver implementation, it seems like > +the TX/RX flow control is enabled only if the flow control pause option > +is resolved from the device/link partner advertisements (or otherwise set). > + > +On the other hand, our current in-tree driver force enables TX/RX flow > +control by default, thus possibly leading to TX timeouts if the other > +end sends pause frames (which are not properly handled?): > + > + WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:320 > + dev_watchdog+0x1ac/0x324 NETDEV WATCHDOG: eth0 (mtk_soc_eth): > transmit > + queue 0 timed out > + > +Disabling the flow control on PORT 5 MAC seems to fix this issues as > +the pause frames are then filtered out. While at it, I'm removing the > +if condition completely as suggested, since this code is run only on > +mt7621 SoC, so there is no need to check for the silicon revisions. > + > +Ref: > +https://lists.openwrt.org/pipermail/openwrt-devel/2017- > November/009882. > +html > +Ref: > +https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after- > r11573/5 > +0000/12 > +Suggested-by: Felix Fietkau <nbd@nbd.name> > +Reported-by: Rosen Penev <rosenp@gmail.com> > +Signed-off-by: Petr Štetiar <ynezz@true.cz> (cherry picked from commit > +c8f8e59816eca49d776562d2d302bf990a87faf0) > +--- > + .../drivers/net/ethernet/mediatek/gsw_mt7621.c | 12 +++--------- > + 1 file changed, 3 insertions(+), 9 deletions(-) > + > +diff --git > +a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt76 > +21.c > +b/target/linux/ramips/files- > 4.14/drivers/net/ethernet/mediatek/gsw_mt76 > +21.c index 89be23900738..232bcd8cf4ea 100644 > +--- > +a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt76 > +21.c > ++++ b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_ > ++++ mt7621.c > +@@ -98,15 +98,9 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw, > struct device_node *np) > + mt7530_mdio_w32(gsw, 0x7000, 0x3); > + usleep_range(10, 20); > + > +- if ((rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0xFFFF) == 0x0101) { > +- /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */ > +- mtk_switch_w32(gsw, 0x2305e30b, > GSW_REG_MAC_P0_MCR); > +- mt7530_mdio_w32(gsw, 0x3600, 0x5e30b); > +- } else { > +- /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */ > +- mtk_switch_w32(gsw, 0x2305e33b, > GSW_REG_MAC_P0_MCR); > +- mt7530_mdio_w32(gsw, 0x3600, 0x5e33b); > +- } > ++ /* (GE1, Force 1000M/FD, FC OFF, MAX_RX_LENGTH 1536) */ > ++ mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR); > ++ mt7530_mdio_w32(gsw, 0x3600, 0x5e30b); > + > + /* (GE2, Link down) */ > + mtk_switch_w32(gsw, 0x8000, GSW_REG_MAC_P1_MCR); > -- > 2.28.0
Currently devices based on mt7621 might freeze due to issues with the ethernet driver. (see [1]) This patch might fix these freezes and will be included in OpenWrt 19.07.4 [2]. While it is hard to reproduce the issue and this patch is therefore not verified to fix the issue, it is backported into our firmware anyway. This patch can be removed when upgrading to OpenWrt 19.07.4. [1] https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573 [2] https://github.com/openwrt/openwrt/commit/c8f8e59816eca49d776562d2d302bf990a87faf0 Signed-off-by: Fabian Bläse <fabian@blaese.de> --- .../0010-ramips-gsw_mt7621-disable-PORT.patch | 58 +++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 build_patches/openwrt/0010-ramips-gsw_mt7621-disable-PORT.patch