| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <DB8PR04MB6795BB20842D377DF285BB5FE6939@DB8PR04MB6795.eurprd04.prod.outlook.com>
Date: Mon, 8 Mar 2021 12:45:49 +0000
From: Joakim Zhang <qiangqing.zhang@....com>
To: Florian Fainelli <f.fainelli@...il.com>,
Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: stmmac driver timeout issue
Hi Florian, Andrew,
Thanks for your help, after debug, It seems related to PHY(RTL8211FDI). It stop output RXC clock for dozens to hundreds milliseconds during auto-negotiation, and there is no such issue with AR8031.
When do ifup/ifdown test or system suspend/resume test, it will suspend then resume phy which do power down and then change to normal operation.(switch from power to normal operation)
There is a note in RTL8211FDI datasheet:
Note 2: When the RTL8211F(I)/RTL8211FD(I) is switched from power to normal operation, a software reset and restart auto-negotiation is performed, even if bits Reset(0.15) and Restart_AN(0.9) are not set by the users.
Form above note, it will trigger auto-negotiation when do ifup/ifdown test or system suspend/resume, so we will meet RXC clock is stop issue on RTL8211FDI. My question is that, Is this a normal behavior, all PHYs will perform this behavior? And Linux PHY frame work can handle this case, there is no config_init after resume, will the config be reset?
Best Regards,
Joakim Zhang
> -----Original Message-----
> From: Florian Fainelli <f.fainelli@...il.com>
> Sent: 2021年3月5日 8:28
> To: Joakim Zhang <qiangqing.zhang@....com>; Jakub Kicinski
> <kuba@...nel.org>; Andrew Lunn <andrew@...n.ch>
> Cc: netdev@...r.kernel.org
> Subject: Re: stmmac driver timeout issue
>
> On 3/4/21 5:14 AM, Joakim Zhang wrote:
> >
> > Hello Andrew, Hello Jakub,
> >
> > You may can give some suggestions based on your great networking
> knowledge, thanks in advance!
> >
> > I found that add vlan id hw filter (stmmac_vlan_rx_add_vid) have possibility
> timeout when accessing VLAN Filter registers during ifup/ifdown stress test,
> and restore vlan id hw filter (stmmac_restore_hw_vlan_rx_fltr) always timeout
> when access VLAN Filter registers.
> >
> > My hardware is i.MX8MP
> (drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c, RGMII interface,
> RTL8211FDI-CG PHY), it needs fix mac speed(imx_dwmac_fix_speed), it
> indirectly involved in phylink_link_up. After debugging, if phylink_link_up is
> called later than adding vlan id hw filter, it will report timeout, so I guess we
> need fix mac speed before accessing VLAN Filter registers. Error like below:
> > [ 106.389879] 8021q: adding VLAN 0 to HW filter on device eth1
> > [ 106.395644] imx-dwmac 30bf0000.ethernet eth1: Timeout accessing
> MAC_VLAN_Tag_Filter
> > [ 108.160734] imx-dwmac 30bf0000.ethernet eth1: Link is Up -
> 100Mbps/Full - flow control rx/tx ->->-> which means accessing VLAN Filter
> registers before phylink_link_up is called.
> >
> > Same case when system resume back,
> > [ 1763.842294] imx-dwmac 30bf0000.ethernet eth1: configuring for
> phy/rgmii-id link mode
> > [ 1763.853084] imx-dwmac 30bf0000.ethernet eth1: No Safety Features
> support found
> > [ 1763.853186] imx-dwmac 30bf0000.ethernet eth1: Timeout accessing
> MAC_VLAN_Tag_Filter
> > [ 1763.873465] usb usb1: root hub lost power or was reset
> > [ 1763.873469] usb usb2: root hub lost power or was reset
> > [ 1764.090321] PM: resume devices took 0.248 seconds
> > [ 1764.257381] OOM killer enabled.
> > [ 1764.260518] Restarting tasks ... done.
> > [ 1764.265229] PM: suspend exit
> > ===============================
> > suspend 12 times
> > ===============================
> > [ 1765.887915] imx-dwmac 30bf0000.ethernet eth1: Link is Up -
> 100Mbps/Full - flow control rx/tx ->->-> which means accessing VLAN Filter
> registers before phylink_link_up is called.
> >
> > My question is that some MAC controllers need RXC clock from RGMII
> interface to reset DAM or access to some registers. If there is any way to
> ensure phylink_link_up is invoked synchronously when we need it. I am not sure
> this timeout caused by a fix mac speed is needed before accessing VLAN Filter
> registers, is there ang hints, thanks a lot! We have another board i.MX8DXL
> which don't need fix mac speed attach to AR8031 PHY, can't reproduce this
> issue.
>
> Every Ethernet controller is different, but you can see that we struggled to fix a
> similar problem where we need the RXC from the PHY for the MAC to complete
> its reset side reset with GENET, it took several iterations to get there:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fco
> mmit%2F%3Fid%3D88f6c8bf1aaed5039923fb4c701cab4d42176275&data
> =04%7C01%7Cqiangqing.zhang%40nxp.com%7Cbe0cffc475f946efac1908d8df6
> d97f8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637505009093
> 274835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ar2KLapqP3u
> w%2FKlQF5KOkKwgelCZefaW%2FDk5gS8td%2Fc%3D&reserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fco
> mmit%2F%3Fid%3D612eb1c3b9e504de24136c947ed7c07bc342f3aa&dat
> a=04%7C01%7Cqiangqing.zhang%40nxp.com%7Cbe0cffc475f946efac1908d8df
> 6d97f8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63750500909
> 3274835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YgHMDS5d%
> 2FT3y%2FLOK4Y3nyOWvWdmpMcj4UmaTJCwJnpQ%3D&reserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fco
> mmit%2F%3Fid%3D6b6d017fccb4693767d2fcae9ef2fd05243748bb&data=
> 04%7C01%7Cqiangqing.zhang%40nxp.com%7Cbe0cffc475f946efac1908d8df6d
> 97f8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6375050090932
> 74835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9A6zO4NIbgn
> %2BAizlmPdOj5GwxYhln7OFsAp6sFFrpE4%3D&reserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fco
> mmit%2F%3Fid%3D3a55402c93877d291b0a612d25edb03d1b4b93ac&dat
> a=04%7C01%7Cqiangqing.zhang%40nxp.com%7Cbe0cffc475f946efac1908d8df
> 6d97f8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63750500909
> 3274835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QwQ2E6arYR
> x8vQ4dLonrDcl0LhulbOn%2FEJUSZArvt1g%3D&reserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fco
> mmit%2F%3Fid%3D1f515486275a08a17a2c806b844cca18f7de5b34&data
> =04%7C01%7Cqiangqing.zhang%40nxp.com%7Cbe0cffc475f946efac1908d8df6
> d97f8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637505009093
> 274835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VucX1Wgnoz
> MpEmcZolLoYUy2%2FEnJbsn6JxLzZF9SkmE%3D&reserved=0
>
> This driver uses PHYLIB (hardware is no longer developed and will not receive
> updates to support different PCS), but maybe you can glean some idea on how
> to solve this?
> --
> Florian
Powered by blists - more mailing lists