net: stmmac: dwmac-imx: half duplex crash

net: stmmac: dwmac-imx: half duplex crash

[Marcel Ziswiler]

Hi there

We lately tried operating the IMX8MPEVK ENET_QOS imx-dwmac driver in half-duplex modes which crashes as
follows:

root@imx8mpevk:~# uname -a
Linux imx8mpevk 5.18.0-rc2-next-20220413-00006-gc741306ff2ed #4 SMP PREEMPT Wed Apr 13 15:08:36 CEST 2022
aarch64 aarch64 aarch64 GNU/Linux
root@imx8mpevk:~# ethtool -s eth1 advertise 0x004
[  469.685304] imx-dwmac 30bf0000.ethernet eth1: Link is Down
[  469.703528] kauditd_printk_skb: 1 callbacks suppressed
[  469.703539] audit: type=1334 audit(1650754238.319:23): prog-id=17 op=LOAD
[  469.715602] audit: type=1334 audit(1650754238.327:24): prog-id=18 op=LOAD
[  472.737884] imx-dwmac 30bf0000.ethernet eth1: Link is Up - 100Mbps/Half - flow control off
[  472.746205] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  478.080481] ------------[ cut here ]------------
[  478.085134] NETDEV WATCHDOG: eth1 (imx-dwmac): transmit queue 1 timed out
[  478.091985] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x200/0x210
[  478.100269] Modules linked in: 8021q garp mrp stp llc overlay bluetooth ecdh_generic ecc rfkill caam_jr
caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes dwmac_imx stmmac_platform imx_sdma
crct10dif_ce fsl_imx8_ddr_perf stmmac pcs_xpcs etnaviv gpu_sched flexcan caam snvs_pwrkey error can_dev
rtc_snvs imx_cpufreq_dt imx8mm_thermal fuse drm ipv6
[  478.132142] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.18.0-rc2-next-20220413-00006-gc741306ff2ed #4
[  478.141364] Hardware name: NXP i.MX8MPlus EVK board (DT)
[  478.146676] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  478.153644] pc : dev_watchdog+0x200/0x210
[  478.157662] lr : dev_watchdog+0x200/0x210
[  478.161680] sp : ffff80000a3b3a70
[  478.164992] x29: ffff80000a3b3a70 x28: 0000000000000005 x27: ffff800008e57600
[  478.172140] x26: ffff800009ef79c0 x25: ffff00017f3c7fe8 x24: ffff80000a3b3b40
[  478.179283] x23: ffff800009ef7000 x22: 0000000000000001 x21: ffff0000c4cc039c
[  478.186428] x20: ffff0000c4cc0000 x19: ffff0000c4cc0448 x18: 0000000000000030
[  478.193571] x17: ffff800175a13000 x16: ffff80000a2e4000 x15: ffffffffffffffff
[  478.200713] x14: ffff800009f12388 x13: 00000000000004ec x12: 00000000000001a4
[  478.207860] x11: 712074696d736e61 x10: ffff800009f6a388 x9 : 00000000fffff000
[  478.215003] x8 : ffff800009f12388 x7 : 0000000000000003 x6 : 0000000000000000
[  478.222146] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[  478.229294] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c01a0000
[  478.236439] Call trace:
[  478.238886]  dev_watchdog+0x200/0x210
[  478.242556]  call_timer_fn.constprop.0+0x24/0x80
[  478.247182]  __run_timers.part.0+0x1f4/0x23c
[  478.251454]  run_timer_softirq+0x3c/0x7c
[  478.255384]  __do_softirq+0x124/0x2a0
[  478.259047]  __irq_exit_rcu+0xe4/0x100
[  478.262804]  irq_exit_rcu+0x10/0x1c
[  478.266300]  el1_interrupt+0x38/0x70
[  478.269881]  el1h_64_irq_handler+0x18/0x24
[  478.273988]  el1h_64_irq+0x64/0x68
[  478.277393]  arch_cpu_idle+0x18/0x2c
[  478.280969]  default_idle_call+0x24/0x6c
[  478.284900]  do_idle+0x22c/0x29c
[  478.288133]  cpu_startup_entry+0x28/0x30
[  478.292065]  secondary_start_kernel+0x140/0x164
[  478.296600]  __secondary_switched+0xa0/0xa4
[  478.300789] ---[ end trace 0000000000000000 ]---
[  478.305451] imx-dwmac 30bf0000.ethernet eth1: Reset adapter.
[  478.332901] imx-dwmac 30bf0000.ethernet eth1: FPE workqueue stop
[  478.339233] imx-dwmac 30bf0000.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter
[  478.346962] imx-dwmac 30bf0000.ethernet eth1: failed to kill vid 0081/0
[  478.556494] imx-dwmac 30bf0000.ethernet eth1: PHY [stmmac-1:01] driver [RTL8211F Gigabit Ethernet]
(irq=POLL)
[  478.736560] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[  478.744388] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[  478.752222] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[  478.760126] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[  478.767951] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-4
[  478.784520] imx-dwmac 30bf0000.ethernet eth1: No Safety Features support found
[  478.791787] imx-dwmac 30bf0000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[  478.800227] imx-dwmac 30bf0000.ethernet eth1: registered PTP clock
[  478.806610] imx-dwmac 30bf0000.ethernet eth1: FPE workqueue start
[  478.812774] imx-dwmac 30bf0000.ethernet eth1: configuring for phy/rgmii-id link mode
[  478.848739] 8021q: adding VLAN 0 to HW filter on device eth1

Does anybody have any experience in running dwmac in half-duplex mode? Any suggestions?

BTW: It also crashes the same way running NXP's latest downstream LF5.15.5_1.0.0 which I reported here [1].

[1]
https://community.nxp.com/t5/i-MX-Processors/IMX8MPEVK-ENET-QOS-imx-dwmac-Half-Duplex-Crashes/m-p/1448085#M189597

Cheers

Marcel

net: stmmac: dwmac-imx: half duplex crash

[Marcel Ziswiler]

Hi there

We lately tried operating the IMX8MPEVK ENET_QOS imx-dwmac driver in half-duplex modes which crashes as
follows:

root@imx8mpevk:~# uname -a
Linux imx8mpevk 5.18.0-rc2-next-20220413-00006-gc741306ff2ed #4 SMP PREEMPT Wed Apr 13 15:08:36 CEST 2022
aarch64 aarch64 aarch64 GNU/Linux
root@imx8mpevk:~# ethtool -s eth1 advertise 0x004
[  469.685304] imx-dwmac 30bf0000.ethernet eth1: Link is Down
[  469.703528] kauditd_printk_skb: 1 callbacks suppressed
[  469.703539] audit: type=1334 audit(1650754238.319:23): prog-id=17 op=LOAD
[  469.715602] audit: type=1334 audit(1650754238.327:24): prog-id=18 op=LOAD
[  472.737884] imx-dwmac 30bf0000.ethernet eth1: Link is Up - 100Mbps/Half - flow control off
[  472.746205] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  478.080481] ------------[ cut here ]------------
[  478.085134] NETDEV WATCHDOG: eth1 (imx-dwmac): transmit queue 1 timed out
[  478.091985] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x200/0x210
[  478.100269] Modules linked in: 8021q garp mrp stp llc overlay bluetooth ecdh_generic ecc rfkill caam_jr
caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes dwmac_imx stmmac_platform imx_sdma
crct10dif_ce fsl_imx8_ddr_perf stmmac pcs_xpcs etnaviv gpu_sched flexcan caam snvs_pwrkey error can_dev
rtc_snvs imx_cpufreq_dt imx8mm_thermal fuse drm ipv6
[  478.132142] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.18.0-rc2-next-20220413-00006-gc741306ff2ed #4
[  478.141364] Hardware name: NXP i.MX8MPlus EVK board (DT)
[  478.146676] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  478.153644] pc : dev_watchdog+0x200/0x210
[  478.157662] lr : dev_watchdog+0x200/0x210
[  478.161680] sp : ffff80000a3b3a70
[  478.164992] x29: ffff80000a3b3a70 x28: 0000000000000005 x27: ffff800008e57600
[  478.172140] x26: ffff800009ef79c0 x25: ffff00017f3c7fe8 x24: ffff80000a3b3b40
[  478.179283] x23: ffff800009ef7000 x22: 0000000000000001 x21: ffff0000c4cc039c
[  478.186428] x20: ffff0000c4cc0000 x19: ffff0000c4cc0448 x18: 0000000000000030
[  478.193571] x17: ffff800175a13000 x16: ffff80000a2e4000 x15: ffffffffffffffff
[  478.200713] x14: ffff800009f12388 x13: 00000000000004ec x12: 00000000000001a4
[  478.207860] x11: 712074696d736e61 x10: ffff800009f6a388 x9 : 00000000fffff000
[  478.215003] x8 : ffff800009f12388 x7 : 0000000000000003 x6 : 0000000000000000
[  478.222146] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[  478.229294] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c01a0000
[  478.236439] Call trace:
[  478.238886]  dev_watchdog+0x200/0x210
[  478.242556]  call_timer_fn.constprop.0+0x24/0x80
[  478.247182]  __run_timers.part.0+0x1f4/0x23c
[  478.251454]  run_timer_softirq+0x3c/0x7c
[  478.255384]  __do_softirq+0x124/0x2a0
[  478.259047]  __irq_exit_rcu+0xe4/0x100
[  478.262804]  irq_exit_rcu+0x10/0x1c
[  478.266300]  el1_interrupt+0x38/0x70
[  478.269881]  el1h_64_irq_handler+0x18/0x24
[  478.273988]  el1h_64_irq+0x64/0x68
[  478.277393]  arch_cpu_idle+0x18/0x2c
[  478.280969]  default_idle_call+0x24/0x6c
[  478.284900]  do_idle+0x22c/0x29c
[  478.288133]  cpu_startup_entry+0x28/0x30
[  478.292065]  secondary_start_kernel+0x140/0x164
[  478.296600]  __secondary_switched+0xa0/0xa4
[  478.300789] ---[ end trace 0000000000000000 ]---
[  478.305451] imx-dwmac 30bf0000.ethernet eth1: Reset adapter.
[  478.332901] imx-dwmac 30bf0000.ethernet eth1: FPE workqueue stop
[  478.339233] imx-dwmac 30bf0000.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter
[  478.346962] imx-dwmac 30bf0000.ethernet eth1: failed to kill vid 0081/0
[  478.556494] imx-dwmac 30bf0000.ethernet eth1: PHY [stmmac-1:01] driver [RTL8211F Gigabit Ethernet]
(irq=POLL)
[  478.736560] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[  478.744388] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[  478.752222] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[  478.760126] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[  478.767951] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-4
[  478.784520] imx-dwmac 30bf0000.ethernet eth1: No Safety Features support found
[  478.791787] imx-dwmac 30bf0000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[  478.800227] imx-dwmac 30bf0000.ethernet eth1: registered PTP clock
[  478.806610] imx-dwmac 30bf0000.ethernet eth1: FPE workqueue start
[  478.812774] imx-dwmac 30bf0000.ethernet eth1: configuring for phy/rgmii-id link mode
[  478.848739] 8021q: adding VLAN 0 to HW filter on device eth1

Does anybody have any experience in running dwmac in half-duplex mode? Any suggestions?

BTW: It also crashes the same way running NXP's latest downstream LF5.15.5_1.0.0 which I reported here [1].

[1]
https://community.nxp.com/t5/i-MX-Processors/IMX8MPEVK-ENET-QOS-imx-dwmac-Half-Duplex-Crashes/m-p/1448085#M189597

Cheers

Marcel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: stmmac: dwmac-imx: half duplex crash

[Andrew Lunn]

On Sat, Apr 23, 2022 at 10:58:07PM +0000, Marcel Ziswiler wrote:
> Hi there
> 
> We lately tried operating the IMX8MPEVK ENET_QOS imx-dwmac driver in half-duplex modes which crashes as
> follows:

How many transmit queues do you have in operation:

       /* Half-Duplex can only work with single queue */
        if (priv->plat->tx_queues_to_use > 1)
                priv->phylink_config.mac_capabilities &=
                        ~(MAC_10HD | MAC_100HD | MAC_1000HD);

What does ethtool show before you force it? Does it actually list the
HALF modes?

     Andrew

Re: net: stmmac: dwmac-imx: half duplex crash

[Andrew Lunn]

On Sat, Apr 23, 2022 at 10:58:07PM +0000, Marcel Ziswiler wrote:
> Hi there
> 
> We lately tried operating the IMX8MPEVK ENET_QOS imx-dwmac driver in half-duplex modes which crashes as
> follows:

How many transmit queues do you have in operation:

       /* Half-Duplex can only work with single queue */
        if (priv->plat->tx_queues_to_use > 1)
                priv->phylink_config.mac_capabilities &=
                        ~(MAC_10HD | MAC_100HD | MAC_1000HD);

What does ethtool show before you force it? Does it actually list the
HALF modes?

     Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: stmmac: dwmac-imx: half duplex crash

[Marcel Ziswiler]

Hi Andrew

Thanks for your help!

On Mon, 2022-04-25 at 00:01 +0200, Andrew Lunn wrote:
> On Sat, Apr 23, 2022 at 10:58:07PM +0000, Marcel Ziswiler wrote:
> > Hi there
> > 
> > We lately tried operating the IMX8MPEVK ENET_QOS imx-dwmac driver in half-duplex modes which crashes as
> > follows:
> 
> How many transmit queues do you have in operation:

Looks like NXP defaults to 5 RX and TX queues each being setup via device tree [1]. Unfortunately, upon boot
the driver only reports the RX side of things:

[    7.239604] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0

>        /* Half-Duplex can only work with single queue */
>         if (priv->plat->tx_queues_to_use > 1)
>                 priv->phylink_config.mac_capabilities &=
>                         ~(MAC_10HD | MAC_100HD | MAC_1000HD);
> 
> What does ethtool show before you force it? Does it actually list the
> HALF modes?

Good point. I was blinded by NXP downstream which, while listing all incl. 10baseT/Half and 100baseT/Half as
supported link modes, also does not work. However, upstream indeed shows only full-duplex modes as supported:

root@verdin-imx8mp-07106916:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Full 
                                100baseT/Full 
                                1000baseT/Full 
...

Once I remove them queues being setup via device tree it shows all modes as supported again:

root@verdin-imx8mp-07106916:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
...

However, 10baseT/Half, while no longer just crashing, still does not seem to work right. Looking at wireshark
traces it does send packets but seems not to ever get neither ARP nor DHCP answers (as well as any other packet
for that matter). Looks like the same actually applies to 10baseT/Full as well. While 100baseT/Half and
100baseT/Full work fine now.

Any idea what else could still be going wrong with them 10baseT modes?

I do know that eth0 which is FEC based instead, works just fine with any and all those modes so my network
setup otherwise seems sound.

Also the question remains, why ethtool allows such illegal configuration and even worse why the kernel
subsequently just crashes. Not sure how exactly this could be prevented though.

On a side note, besides modifying the device tree for such single-queue setup being half-duplex capable, is
there any easier way? Much nicer would, of course, be if it justworkedTM (e.g. advertise all modes but once a
half-duplex mode is chosen revert to such single-queue operation). Then, on the other hand, who still uses
half-duplex communication in this day and age (;-p).

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/freescale/imx8mp-evk.dts?h=v5.18-rc4#n110

>      Andrew

Cheers

Marcel

Re: net: stmmac: dwmac-imx: half duplex crash

[Marcel Ziswiler]

Hi Andrew

Thanks for your help!

On Mon, 2022-04-25 at 00:01 +0200, Andrew Lunn wrote:
> On Sat, Apr 23, 2022 at 10:58:07PM +0000, Marcel Ziswiler wrote:
> > Hi there
> > 
> > We lately tried operating the IMX8MPEVK ENET_QOS imx-dwmac driver in half-duplex modes which crashes as
> > follows:
> 
> How many transmit queues do you have in operation:

Looks like NXP defaults to 5 RX and TX queues each being setup via device tree [1]. Unfortunately, upon boot
the driver only reports the RX side of things:

[    7.239604] imx-dwmac 30bf0000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0

>        /* Half-Duplex can only work with single queue */
>         if (priv->plat->tx_queues_to_use > 1)
>                 priv->phylink_config.mac_capabilities &=
>                         ~(MAC_10HD | MAC_100HD | MAC_1000HD);
> 
> What does ethtool show before you force it? Does it actually list the
> HALF modes?

Good point. I was blinded by NXP downstream which, while listing all incl. 10baseT/Half and 100baseT/Half as
supported link modes, also does not work. However, upstream indeed shows only full-duplex modes as supported:

root@verdin-imx8mp-07106916:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Full 
                                100baseT/Full 
                                1000baseT/Full 
...

Once I remove them queues being setup via device tree it shows all modes as supported again:

root@verdin-imx8mp-07106916:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
...

However, 10baseT/Half, while no longer just crashing, still does not seem to work right. Looking at wireshark
traces it does send packets but seems not to ever get neither ARP nor DHCP answers (as well as any other packet
for that matter). Looks like the same actually applies to 10baseT/Full as well. While 100baseT/Half and
100baseT/Full work fine now.

Any idea what else could still be going wrong with them 10baseT modes?

I do know that eth0 which is FEC based instead, works just fine with any and all those modes so my network
setup otherwise seems sound.

Also the question remains, why ethtool allows such illegal configuration and even worse why the kernel
subsequently just crashes. Not sure how exactly this could be prevented though.

On a side note, besides modifying the device tree for such single-queue setup being half-duplex capable, is
there any easier way? Much nicer would, of course, be if it justworkedTM (e.g. advertise all modes but once a
half-duplex mode is chosen revert to such single-queue operation). Then, on the other hand, who still uses
half-duplex communication in this day and age (;-p).

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/freescale/imx8mp-evk.dts?h=v5.18-rc4#n110

>      Andrew

Cheers

Marcel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: stmmac: dwmac-imx: half duplex crash

[Andrew Lunn]

> Good point. I was blinded by NXP downstream which, while listing all incl. 10baseT/Half and 100baseT/Half as
> supported link modes, also does not work. However, upstream indeed shows only full-duplex modes as supported:
> 
> root@verdin-imx8mp-07106916:~# ethtool eth1
> Settings for eth1:
>         Supported ports: [ TP MII ]
>         Supported link modes:   10baseT/Full 
>                                 100baseT/Full 
>                                 1000baseT/Full 

So maybe we actually want ethtool to report -EINVAL when asked to do
something which is not supported! Humm:

https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/phy.c#L783


	/* We make sure that we don't pass unsupported values in to the PHY */
	linkmode_and(advertising, advertising, phydev->supported);

So maybe the unsupported mode got removed, and the PHY was asked to
advertise nothing!

Anyway, this is roughly there the check should go.

> ...
> 
> Once I remove them queues being setup via device tree it shows all modes as supported again:
> 
> root@verdin-imx8mp-07106916:~# ethtool eth1
> Settings for eth1:
>         Supported ports: [ TP MII ]
>         Supported link modes:   10baseT/Half 10baseT/Full 
>                                 100baseT/Half 100baseT/Full 
>                                 1000baseT/Full 
> ...
> 
> However, 10baseT/Half, while no longer just crashing, still does not seem to work right. Looking at wireshark
> traces it does send packets but seems not to ever get neither ARP nor DHCP answers (as well as any other packet
> for that matter).

So the answers are on the wire, just not received? 

> Looks like the same actually applies to 10baseT/Full as well. While 100baseT/Half and
> 100baseT/Full work fine now.
> 
> Any idea what else could still be going wrong with them 10baseT modes?

I would use mii-tool to check the status of the PHY. Make sure it
really has negotiated 10/Half mode. After that, it is very likely to
be a MAC problem, and i don't think i can help you.

> On a side note, besides modifying the device tree for such single-queue setup being half-duplex capable, is
> there any easier way? Much nicer would, of course, be if it justworkedTM (e.g. advertise all modes but once a
> half-duplex mode is chosen revert to such single-queue operation). Then, on the other hand, who still uses
> half-duplex communication in this day and age (;-p).

You seem to need it for some reason!

Anyway, it is just code. You have all the needed information in the
adjust_link callback, so you could implement it.

	    Andrew

Re: net: stmmac: dwmac-imx: half duplex crash

[Andrew Lunn]

> Good point. I was blinded by NXP downstream which, while listing all incl. 10baseT/Half and 100baseT/Half as
> supported link modes, also does not work. However, upstream indeed shows only full-duplex modes as supported:
> 
> root@verdin-imx8mp-07106916:~# ethtool eth1
> Settings for eth1:
>         Supported ports: [ TP MII ]
>         Supported link modes:   10baseT/Full 
>                                 100baseT/Full 
>                                 1000baseT/Full 

So maybe we actually want ethtool to report -EINVAL when asked to do
something which is not supported! Humm:

https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/phy.c#L783


	/* We make sure that we don't pass unsupported values in to the PHY */
	linkmode_and(advertising, advertising, phydev->supported);

So maybe the unsupported mode got removed, and the PHY was asked to
advertise nothing!

Anyway, this is roughly there the check should go.

> ...
> 
> Once I remove them queues being setup via device tree it shows all modes as supported again:
> 
> root@verdin-imx8mp-07106916:~# ethtool eth1
> Settings for eth1:
>         Supported ports: [ TP MII ]
>         Supported link modes:   10baseT/Half 10baseT/Full 
>                                 100baseT/Half 100baseT/Full 
>                                 1000baseT/Full 
> ...
> 
> However, 10baseT/Half, while no longer just crashing, still does not seem to work right. Looking at wireshark
> traces it does send packets but seems not to ever get neither ARP nor DHCP answers (as well as any other packet
> for that matter).

So the answers are on the wire, just not received? 

> Looks like the same actually applies to 10baseT/Full as well. While 100baseT/Half and
> 100baseT/Full work fine now.
> 
> Any idea what else could still be going wrong with them 10baseT modes?

I would use mii-tool to check the status of the PHY. Make sure it
really has negotiated 10/Half mode. After that, it is very likely to
be a MAC problem, and i don't think i can help you.

> On a side note, besides modifying the device tree for such single-queue setup being half-duplex capable, is
> there any easier way? Much nicer would, of course, be if it justworkedTM (e.g. advertise all modes but once a
> half-duplex mode is chosen revert to such single-queue operation). Then, on the other hand, who still uses
> half-duplex communication in this day and age (;-p).

You seem to need it for some reason!

Anyway, it is just code. You have all the needed information in the
adjust_link callback, so you could implement it.

	    Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: stmmac: dwmac-imx: half duplex crash

[Marcel Ziswiler]

On Mon, 2022-04-25 at 17:59 +0200, Andrew Lunn wrote:
> > Good point. I was blinded by NXP downstream which, while listing all incl. 10baseT/Half and 100baseT/Half
> > as
> > supported link modes, also does not work. However, upstream indeed shows only full-duplex modes as
> > supported:
> > 
> > root@verdin-imx8mp-07106916:~# ethtool eth1
> > Settings for eth1:
> >         Supported ports: [ TP MII ]
> >         Supported link modes:   10baseT/Full 
> >                                 100baseT/Full 
> >                                 1000baseT/Full 
> 
> So maybe we actually want ethtool to report -EINVAL when asked to do
> something which is not supported! Humm:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/phy.c#L783
> 
> 
>         /* We make sure that we don't pass unsupported values in to the PHY */
>         linkmode_and(advertising, advertising, phydev->supported);
> 
> So maybe the unsupported mode got removed, and the PHY was asked to
> advertise nothing!

Yeah, that's also what I was suspecting.

And running ethtool again after the crash kinda supports this theory.

root@verdin-imx8mp-07106916:~# ethtool -s eth1 advertise 0x01

=> crash

root@verdin-imx8mp-07106916:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Full 
                                100baseT/Full 
                                1000baseT/Full 
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
                                ^^^^^^^^^^^^
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 7
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: ug
        Wake-on: d
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
        Link detected: no

> Anyway, this is roughly there the check should go.

You mean it would need an additional check against advertising nothing?

> > ...
> > 
> > Once I remove them queues being setup via device tree it shows all modes as supported again:
> > 
> > root@verdin-imx8mp-07106916:~# ethtool eth1
> > Settings for eth1:
> >         Supported ports: [ TP MII ]
> >         Supported link modes:   10baseT/Half 10baseT/Full 
> >                                 100baseT/Half 100baseT/Full 
> >                                 1000baseT/Full 
> > ...
> > 
> > However, 10baseT/Half, while no longer just crashing, still does not seem to work right. Looking at
> > wireshark
> > traces it does send packets but seems not to ever get neither ARP nor DHCP answers (as well as any other
> > packet
> > for that matter).
> 
> So the answers are on the wire, just not received?

Yes, judging from the wireshark trace that is exactly how it looks.

> > Looks like the same actually applies to 10baseT/Full as well. While 100baseT/Half and
> > 100baseT/Full work fine now.
> > 
> > Any idea what else could still be going wrong with them 10baseT modes?
> 
> I would use mii-tool to check the status of the PHY. Make sure it
> really has negotiated 10/Half mode.

Yes, it looks like it.

root@verdin-imx8mp-07106916:~# mii-tool
eth0: negotiated 10baseT-HD, link ok
eth1: negotiated 10baseT-HD, link ok

As a matter of fact, the exact same KSZ9131RNXI PHY albeit on FEC MAC eth0 works just fine with 10Mbps half-
duplex.

> After that, it is very likely to
> be a MAC problem, and i don't think i can help you.

Sure, anyway, thanks again for all your suggestions so far. I hope somebody more familiar with the DWMAC side
of things might chime in now...

> > On a side note, besides modifying the device tree for such single-queue setup being half-duplex capable, is
> > there any easier way? Much nicer would, of course, be if it justworkedTM (e.g. advertise all modes but once
> > a
> > half-duplex mode is chosen revert to such single-queue operation). Then, on the other hand, who still uses
> > half-duplex communication in this day and age (;-p).
> 
> You seem to need it for some reason!

Well, we are gearing up on our automated testing infrastructure and asking my humble opinion on what exactly to
test concerning the Ethernet subsystem I gave the brilliant suggestion to try each and every supported link
mode (;-p). Which actually works just fine on every other hardware of ours just not the i.MX 8M Plus with the
DWMAC IP (remember, even FEC MAC works). So for now this is not something a customer of ours has real trouble
with but it raised some questions concerning whether or not and what exactly we do support...

> Anyway, it is just code. You have all the needed information in the
> adjust_link callback, so you could implement it.

Yeah, I guess that might be a neat little side project trying to get more into the topic. So far much of the
interaction within the networking subsystem in Linux is still rather a miracle to me...

>             Andrew

Cheers

Marcel

Re: net: stmmac: dwmac-imx: half duplex crash

[Marcel Ziswiler]

On Mon, 2022-04-25 at 17:59 +0200, Andrew Lunn wrote:
> > Good point. I was blinded by NXP downstream which, while listing all incl. 10baseT/Half and 100baseT/Half
> > as
> > supported link modes, also does not work. However, upstream indeed shows only full-duplex modes as
> > supported:
> > 
> > root@verdin-imx8mp-07106916:~# ethtool eth1
> > Settings for eth1:
> >         Supported ports: [ TP MII ]
> >         Supported link modes:   10baseT/Full 
> >                                 100baseT/Full 
> >                                 1000baseT/Full 
> 
> So maybe we actually want ethtool to report -EINVAL when asked to do
> something which is not supported! Humm:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/phy.c#L783
> 
> 
>         /* We make sure that we don't pass unsupported values in to the PHY */
>         linkmode_and(advertising, advertising, phydev->supported);
> 
> So maybe the unsupported mode got removed, and the PHY was asked to
> advertise nothing!

Yeah, that's also what I was suspecting.

And running ethtool again after the crash kinda supports this theory.

root@verdin-imx8mp-07106916:~# ethtool -s eth1 advertise 0x01

=> crash

root@verdin-imx8mp-07106916:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Full 
                                100baseT/Full 
                                1000baseT/Full 
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
                                ^^^^^^^^^^^^
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 7
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: ug
        Wake-on: d
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
        Link detected: no

> Anyway, this is roughly there the check should go.

You mean it would need an additional check against advertising nothing?

> > ...
> > 
> > Once I remove them queues being setup via device tree it shows all modes as supported again:
> > 
> > root@verdin-imx8mp-07106916:~# ethtool eth1
> > Settings for eth1:
> >         Supported ports: [ TP MII ]
> >         Supported link modes:   10baseT/Half 10baseT/Full 
> >                                 100baseT/Half 100baseT/Full 
> >                                 1000baseT/Full 
> > ...
> > 
> > However, 10baseT/Half, while no longer just crashing, still does not seem to work right. Looking at
> > wireshark
> > traces it does send packets but seems not to ever get neither ARP nor DHCP answers (as well as any other
> > packet
> > for that matter).
> 
> So the answers are on the wire, just not received?

Yes, judging from the wireshark trace that is exactly how it looks.

> > Looks like the same actually applies to 10baseT/Full as well. While 100baseT/Half and
> > 100baseT/Full work fine now.
> > 
> > Any idea what else could still be going wrong with them 10baseT modes?
> 
> I would use mii-tool to check the status of the PHY. Make sure it
> really has negotiated 10/Half mode.

Yes, it looks like it.

root@verdin-imx8mp-07106916:~# mii-tool
eth0: negotiated 10baseT-HD, link ok
eth1: negotiated 10baseT-HD, link ok

As a matter of fact, the exact same KSZ9131RNXI PHY albeit on FEC MAC eth0 works just fine with 10Mbps half-
duplex.

> After that, it is very likely to
> be a MAC problem, and i don't think i can help you.

Sure, anyway, thanks again for all your suggestions so far. I hope somebody more familiar with the DWMAC side
of things might chime in now...

> > On a side note, besides modifying the device tree for such single-queue setup being half-duplex capable, is
> > there any easier way? Much nicer would, of course, be if it justworkedTM (e.g. advertise all modes but once
> > a
> > half-duplex mode is chosen revert to such single-queue operation). Then, on the other hand, who still uses
> > half-duplex communication in this day and age (;-p).
> 
> You seem to need it for some reason!

Well, we are gearing up on our automated testing infrastructure and asking my humble opinion on what exactly to
test concerning the Ethernet subsystem I gave the brilliant suggestion to try each and every supported link
mode (;-p). Which actually works just fine on every other hardware of ours just not the i.MX 8M Plus with the
DWMAC IP (remember, even FEC MAC works). So for now this is not something a customer of ours has real trouble
with but it raised some questions concerning whether or not and what exactly we do support...

> Anyway, it is just code. You have all the needed information in the
> adjust_link callback, so you could implement it.

Yeah, I guess that might be a neat little side project trying to get more into the topic. So far much of the
interaction within the networking subsystem in Linux is still rather a miracle to me...

>             Andrew

Cheers

Marcel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: stmmac: dwmac-imx: half duplex crash

[Andrew Lunn]

> > Anyway, this is roughly there the check should go.
> 
> You mean it would need an additional check against advertising nothing?

I would check for a mode being requested which is not
supported. phydev->supported tells you what the MAC/PHY can actually
do. If there is a bit set which is not a member of that, return
EINVAL. I don't think the plumbing is there, but netlink ethtool
allows you to also return a text message via extack, so you could give
the user a bit more information, the link mode which is invalid.

> Well, we are gearing up on our automated testing infrastructure and asking my humble opinion on what exactly to
> test concerning the Ethernet subsystem I gave the brilliant suggestion to try each and every supported link
> mode (;-p). Which actually works just fine on every other hardware of ours just not the i.MX 8M Plus with the
> DWMAC IP (remember, even FEC MAC works). So for now this is not something a customer of ours has real trouble
> with but it raised some questions concerning whether or not and what exactly we do support...

So in practice, this should not happen. You don't advertise the half
modes, so you should never end up in a half mode. So it is not a
problem :-)

	Andrew

Re: net: stmmac: dwmac-imx: half duplex crash

[Andrew Lunn]

> > Anyway, this is roughly there the check should go.
> 
> You mean it would need an additional check against advertising nothing?

I would check for a mode being requested which is not
supported. phydev->supported tells you what the MAC/PHY can actually
do. If there is a bit set which is not a member of that, return
EINVAL. I don't think the plumbing is there, but netlink ethtool
allows you to also return a text message via extack, so you could give
the user a bit more information, the link mode which is invalid.

> Well, we are gearing up on our automated testing infrastructure and asking my humble opinion on what exactly to
> test concerning the Ethernet subsystem I gave the brilliant suggestion to try each and every supported link
> mode (;-p). Which actually works just fine on every other hardware of ours just not the i.MX 8M Plus with the
> DWMAC IP (remember, even FEC MAC works). So for now this is not something a customer of ours has real trouble
> with but it raised some questions concerning whether or not and what exactly we do support...

So in practice, this should not happen. You don't advertise the half
modes, so you should never end up in a half mode. So it is not a
problem :-)

	Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel