mtk_eth_soc for mt7621 won't work after 6.0-rc1

mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Arınç ÜNAL]

Ethernet for MT7621 SoCs no longer works after changes introduced to 
mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets 
are sent out from the interface fine but won't be received on the interface.

Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY 
connected to gmac1 of the SoC.

Last working kernel is 5.19. The issue is present on 6.0-rc5.

Arınç

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

> Ethernet for MT7621 SoCs no longer works after changes introduced to
> mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
> sent out from the interface fine but won't be received on the interface.
> 
> Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
> connected to gmac1 of the SoC.
> 
> Last working kernel is 5.19. The issue is present on 6.0-rc5.
> 
> Arınç

Hi Arınç,

thx for testing and reporting the issue. Can you please identify
the offending commit running git bisect?

Regards,
Lorenzo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

> > Ethernet for MT7621 SoCs no longer works after changes introduced to
> > mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
> > sent out from the interface fine but won't be received on the interface.
> > 
> > Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
> > connected to gmac1 of the SoC.
> > 
> > Last working kernel is 5.19. The issue is present on 6.0-rc5.
> > 
> > Arınç
> 
> Hi Arınç,
> 
> thx for testing and reporting the issue. Can you please identify
> the offending commit running git bisect?
> 
> Regards,
> Lorenzo

Hi Arınç,

just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
provide more details about your development board/environment?

Regards,
Lorenzo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Arınç ÜNAL]

Hi Lorenzo,

On 12.09.2022 21:01, Lorenzo Bianconi wrote:
>>> Ethernet for MT7621 SoCs no longer works after changes introduced to
>>> mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
>>> sent out from the interface fine but won't be received on the interface.
>>>
>>> Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
>>> connected to gmac1 of the SoC.
>>>
>>> Last working kernel is 5.19. The issue is present on 6.0-rc5.
>>>
>>> Arınç
>>
>> Hi Arınç,
>>
>> thx for testing and reporting the issue. Can you please identify
>> the offending commit running git bisect?
>>
>> Regards,
>> Lorenzo
> 
> Hi Arınç,
> 
> just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
> OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
> provide more details about your development board/environment?

I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's 
gnubee-tools which makes an image with filesystem and any Linux kernel 
of choice with slight modifications (maybe not at all) on the kernel.

https://github.com/neilbrown/gnubee-tools

Sergio experiences the same problem on GB-PC1.

Arınç

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

> Hi Lorenzo,
> 
> On 12.09.2022 21:01, Lorenzo Bianconi wrote:
> > > > Ethernet for MT7621 SoCs no longer works after changes introduced to
> > > > mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
> > > > sent out from the interface fine but won't be received on the interface.
> > > > 
> > > > Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
> > > > connected to gmac1 of the SoC.
> > > > 
> > > > Last working kernel is 5.19. The issue is present on 6.0-rc5.
> > > > 
> > > > Arınç
> > > 
> > > Hi Arınç,
> > > 
> > > thx for testing and reporting the issue. Can you please identify
> > > the offending commit running git bisect?
> > > 
> > > Regards,
> > > Lorenzo
> > 
> > Hi Arınç,
> > 
> > just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
> > OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
> > provide more details about your development board/environment?
> 
> I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's gnubee-tools
> which makes an image with filesystem and any Linux kernel of choice with
> slight modifications (maybe not at all) on the kernel.
> 
> https://github.com/neilbrown/gnubee-tools
> 
> Sergio experiences the same problem on GB-PC1.

ack, can you please run git bisect in order to identify the offending commit?
What is the latest kernel version that is working properly? 5.19.8?

Regards,
Lorenzo

> 
> Arınç

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Sergio Paracuellos]

Hi Lorenzo,

On Mon, Sep 12, 2022 at 10:30 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>
> > Hi Lorenzo,
> >
> > On 12.09.2022 21:01, Lorenzo Bianconi wrote:
> > > > > Ethernet for MT7621 SoCs no longer works after changes introduced to
> > > > > mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
> > > > > sent out from the interface fine but won't be received on the interface.
> > > > >
> > > > > Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
> > > > > connected to gmac1 of the SoC.
> > > > >
> > > > > Last working kernel is 5.19. The issue is present on 6.0-rc5.
> > > > >
> > > > > Arınç
> > > >
> > > > Hi Arınç,
> > > >
> > > > thx for testing and reporting the issue. Can you please identify
> > > > the offending commit running git bisect?
> > > >
> > > > Regards,
> > > > Lorenzo
> > >
> > > Hi Arınç,
> > >
> > > just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
> > > OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
> > > provide more details about your development board/environment?
> >
> > I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's gnubee-tools
> > which makes an image with filesystem and any Linux kernel of choice with
> > slight modifications (maybe not at all) on the kernel.
> >
> > https://github.com/neilbrown/gnubee-tools
> >
> > Sergio experiences the same problem on GB-PC1.
>
> ack, can you please run git bisect in order to identify the offending commit?
> What is the latest kernel version that is working properly? 5.19.8?

I'll try to get time today to properly bisect and identify the
offending commit. I get a working platform with 5.19.8, yes but with
v6-rc-1 my network is totally broken.

Thanks,
    Sergio Paracuellos

>
> Regards,
> Lorenzo
>
> >
> > Arınç

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Sergio Paracuellos]

Hi Lorenzo,

On Tue, Sep 13, 2022 at 5:32 AM Sergio Paracuellos
<sergio.paracuellos@gmail.com> wrote:
>
> Hi Lorenzo,
>
> On Mon, Sep 12, 2022 at 10:30 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> >
> > > Hi Lorenzo,
> > >
> > > On 12.09.2022 21:01, Lorenzo Bianconi wrote:
> > > > > > Ethernet for MT7621 SoCs no longer works after changes introduced to
> > > > > > mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
> > > > > > sent out from the interface fine but won't be received on the interface.
> > > > > >
> > > > > > Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
> > > > > > connected to gmac1 of the SoC.
> > > > > >
> > > > > > Last working kernel is 5.19. The issue is present on 6.0-rc5.
> > > > > >
> > > > > > Arınç
> > > > >
> > > > > Hi Arınç,
> > > > >
> > > > > thx for testing and reporting the issue. Can you please identify
> > > > > the offending commit running git bisect?
> > > > >
> > > > > Regards,
> > > > > Lorenzo
> > > >
> > > > Hi Arınç,
> > > >
> > > > just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
> > > > OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
> > > > provide more details about your development board/environment?
> > >
> > > I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's gnubee-tools
> > > which makes an image with filesystem and any Linux kernel of choice with
> > > slight modifications (maybe not at all) on the kernel.
> > >
> > > https://github.com/neilbrown/gnubee-tools
> > >
> > > Sergio experiences the same problem on GB-PC1.
> >
> > ack, can you please run git bisect in order to identify the offending commit?
> > What is the latest kernel version that is working properly? 5.19.8?
>
> I'll try to get time today to properly bisect and identify the
> offending commit. I get a working platform with 5.19.8, yes but with
> v6-rc-1 my network is totally broken.

+ [cc: Paul E. McKenney <paulmck@kernel.org> as commit author]

Ok, so I have bisected the issue to:
1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more patient
for RCU Tasks boot-time testing

This is the complete bisect log:

$ git bisect log
git bisect start
# good: [70cb6afe0e2ff1b7854d840978b1849bffb3ed21] Linux 5.19.8
git bisect good 70cb6afe0e2ff1b7854d840978b1849bffb3ed21
# bad: [568035b01cfb107af8d2e4bd2fb9aea22cf5b868] Linux 6.0-rc1
git bisect bad 568035b01cfb107af8d2e4bd2fb9aea22cf5b868
# good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19
git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd
# bad: [b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1] Merge tag
'drm-next-2022-08-03' of git://anongit.freedesktop.org/drm/drm
git bisect bad b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1
# bad: [526942b8134cc34d25d27f95dfff98b8ce2f6fcd] Merge tag
'ata-5.20-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
git bisect bad 526942b8134cc34d25d27f95dfff98b8ce2f6fcd
# good: [2e7a95156d64667a8ded606829d57c6fc92e41df] Merge tag
'regmap-v5.20' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
git bisect good 2e7a95156d64667a8ded606829d57c6fc92e41df
# good: [c013d0af81f60cc7dbe357c4e2a925fb6738dbfe] Merge tag
'for-5.20/block-2022-07-29' of git://git.kernel.dk/linux-block
git bisect good c013d0af81f60cc7dbe357c4e2a925fb6738dbfe
# bad: [aad26f55f47a33d6de3df65f0b18e2886059ed6d] Merge tag 'docs-6.0'
of git://git.lwn.net/linux
git bisect bad aad26f55f47a33d6de3df65f0b18e2886059ed6d
# good: [c2a24a7a036b3bd3a2e6c66730dfc777cae6540a] Merge tag
'v5.20-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect good c2a24a7a036b3bd3a2e6c66730dfc777cae6540a
# bad: [34bc7b454dc31f75a0be7ee8ab378135523d7c51] Merge branch
'ctxt.2022.07.05a' into HEAD
git bisect bad 34bc7b454dc31f75a0be7ee8ab378135523d7c51
# bad: [e72ee5e1a866b85cb6c3d4c80a1125976020a7e8] rcu-tasks: Use
delayed_work to delay rcu_tasks_verify_self_tests()
git bisect bad e72ee5e1a866b85cb6c3d4c80a1125976020a7e8
# good: [f90f19da88bfe32dd1fdfd104de4c0526a3be701] rcu-tasks: Make RCU
Tasks Trace stall warning handle idle offline tasks
git bisect good f90f19da88bfe32dd1fdfd104de4c0526a3be701
# good: [dc7d54b45170e1e3ced9f86718aa4274fd727790] rcu-tasks: Pull in
tasks blocked within RCU Tasks Trace readers
git bisect good dc7d54b45170e1e3ced9f86718aa4274fd727790
# good: [e386b6725798eec07facedf4d4bb710c079fd25c] rcu-tasks:
Eliminate RCU Tasks Trace IPIs to online CPUs
git bisect good e386b6725798eec07facedf4d4bb710c079fd25c
# good: [eea3423b162d5d5cdc08af23e8ee2c2d1134fd07] rcu-tasks: Update comments
git bisect good eea3423b162d5d5cdc08af23e8ee2c2d1134fd07
# bad: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more
patient for RCU Tasks boot-time testing
git bisect bad 1cf1144e8473e8c3180ac8b91309e29b6acfd95f
# first bad commit: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f]
rcu-tasks: Be more patient for RCU Tasks boot-time testing

I don't really understand the relationship with my broken network
issue. I am using debian buster and the effect I see is that when the
network interface becomes up it hangs waiting for a "task running to
raise network interfaces". After about one minute the system boots,
the login prompt is shown but I cannot configure at all network
interfaces: dhclient does not respond and manually ifconfig does not
help also:

root@gnubee:~#
root@gnubee:~# dhclient ethblack
^C
root@gnubee:~# ifconfig ethblack 192.168.1.101
root@gnubee:~# ping 19^C
root@gnubee:~# ping 192.168.1.47
PING 192.168.1.47 (192.168.1.47) 56(84) bytes of data.
^C
--- 192.168.1.47 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 120ms

I have tried to revert the bad commit directly in v6.0-rc1 but
conflicts appeared with the git revert command in
'kernel/rcu/tasks.h', so I am not sure what I can do now.

Thanks,
    Sergio Paracuellos

>
> Thanks,
>     Sergio Paracuellos
>
> >
> > Regards,
> > Lorenzo
> >
> > >
> > > Arınç

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Arınç ÜNAL]

On 13.09.2022 11:31, Sergio Paracuellos wrote:
> Hi Lorenzo,
> 
> On Tue, Sep 13, 2022 at 5:32 AM Sergio Paracuellos
> <sergio.paracuellos@gmail.com> wrote:
>>
>> Hi Lorenzo,
>>
>> On Mon, Sep 12, 2022 at 10:30 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>>>
>>>> Hi Lorenzo,
>>>>
>>>> On 12.09.2022 21:01, Lorenzo Bianconi wrote:
>>>>>>> Ethernet for MT7621 SoCs no longer works after changes introduced to
>>>>>>> mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
>>>>>>> sent out from the interface fine but won't be received on the interface.
>>>>>>>
>>>>>>> Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
>>>>>>> connected to gmac1 of the SoC.
>>>>>>>
>>>>>>> Last working kernel is 5.19. The issue is present on 6.0-rc5.
>>>>>>>
>>>>>>> Arınç
>>>>>>
>>>>>> Hi Arınç,
>>>>>>
>>>>>> thx for testing and reporting the issue. Can you please identify
>>>>>> the offending commit running git bisect?
>>>>>>
>>>>>> Regards,
>>>>>> Lorenzo
>>>>>
>>>>> Hi Arınç,
>>>>>
>>>>> just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
>>>>> OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
>>>>> provide more details about your development board/environment?
>>>>
>>>> I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's gnubee-tools
>>>> which makes an image with filesystem and any Linux kernel of choice with
>>>> slight modifications (maybe not at all) on the kernel.
>>>>
>>>> https://github.com/neilbrown/gnubee-tools
>>>>
>>>> Sergio experiences the same problem on GB-PC1.
>>>
>>> ack, can you please run git bisect in order to identify the offending commit?
>>> What is the latest kernel version that is working properly? 5.19.8?
>>
>> I'll try to get time today to properly bisect and identify the
>> offending commit. I get a working platform with 5.19.8, yes but with
>> v6-rc-1 my network is totally broken.
> 
> + [cc: Paul E. McKenney <paulmck@kernel.org> as commit author]
> 
> Ok, so I have bisected the issue to:
> 1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more patient
> for RCU Tasks boot-time testing
> 
> This is the complete bisect log:
> 
> $ git bisect log
> git bisect start
> # good: [70cb6afe0e2ff1b7854d840978b1849bffb3ed21] Linux 5.19.8
> git bisect good 70cb6afe0e2ff1b7854d840978b1849bffb3ed21
> # bad: [568035b01cfb107af8d2e4bd2fb9aea22cf5b868] Linux 6.0-rc1
> git bisect bad 568035b01cfb107af8d2e4bd2fb9aea22cf5b868
> # good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19
> git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd
> # bad: [b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1] Merge tag
> 'drm-next-2022-08-03' of git://anongit.freedesktop.org/drm/drm
> git bisect bad b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1
> # bad: [526942b8134cc34d25d27f95dfff98b8ce2f6fcd] Merge tag
> 'ata-5.20-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
> git bisect bad 526942b8134cc34d25d27f95dfff98b8ce2f6fcd
> # good: [2e7a95156d64667a8ded606829d57c6fc92e41df] Merge tag
> 'regmap-v5.20' of
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
> git bisect good 2e7a95156d64667a8ded606829d57c6fc92e41df
> # good: [c013d0af81f60cc7dbe357c4e2a925fb6738dbfe] Merge tag
> 'for-5.20/block-2022-07-29' of git://git.kernel.dk/linux-block
> git bisect good c013d0af81f60cc7dbe357c4e2a925fb6738dbfe
> # bad: [aad26f55f47a33d6de3df65f0b18e2886059ed6d] Merge tag 'docs-6.0'
> of git://git.lwn.net/linux
> git bisect bad aad26f55f47a33d6de3df65f0b18e2886059ed6d
> # good: [c2a24a7a036b3bd3a2e6c66730dfc777cae6540a] Merge tag
> 'v5.20-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
> git bisect good c2a24a7a036b3bd3a2e6c66730dfc777cae6540a
> # bad: [34bc7b454dc31f75a0be7ee8ab378135523d7c51] Merge branch
> 'ctxt.2022.07.05a' into HEAD
> git bisect bad 34bc7b454dc31f75a0be7ee8ab378135523d7c51
> # bad: [e72ee5e1a866b85cb6c3d4c80a1125976020a7e8] rcu-tasks: Use
> delayed_work to delay rcu_tasks_verify_self_tests()
> git bisect bad e72ee5e1a866b85cb6c3d4c80a1125976020a7e8
> # good: [f90f19da88bfe32dd1fdfd104de4c0526a3be701] rcu-tasks: Make RCU
> Tasks Trace stall warning handle idle offline tasks
> git bisect good f90f19da88bfe32dd1fdfd104de4c0526a3be701
> # good: [dc7d54b45170e1e3ced9f86718aa4274fd727790] rcu-tasks: Pull in
> tasks blocked within RCU Tasks Trace readers
> git bisect good dc7d54b45170e1e3ced9f86718aa4274fd727790
> # good: [e386b6725798eec07facedf4d4bb710c079fd25c] rcu-tasks:
> Eliminate RCU Tasks Trace IPIs to online CPUs
> git bisect good e386b6725798eec07facedf4d4bb710c079fd25c
> # good: [eea3423b162d5d5cdc08af23e8ee2c2d1134fd07] rcu-tasks: Update comments
> git bisect good eea3423b162d5d5cdc08af23e8ee2c2d1134fd07
> # bad: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more
> patient for RCU Tasks boot-time testing
> git bisect bad 1cf1144e8473e8c3180ac8b91309e29b6acfd95f
> # first bad commit: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f]
> rcu-tasks: Be more patient for RCU Tasks boot-time testing
> 
> I don't really understand the relationship with my broken network
> issue. I am using debian buster and the effect I see is that when the
> network interface becomes up it hangs waiting for a "task running to
> raise network interfaces". After about one minute the system boots,
> the login prompt is shown but I cannot configure at all network
> interfaces: dhclient does not respond and manually ifconfig does not
> help also:
> 
> root@gnubee:~#
> root@gnubee:~# dhclient ethblack
> ^C
> root@gnubee:~# ifconfig ethblack 192.168.1.101
> root@gnubee:~# ping 19^C
> root@gnubee:~# ping 192.168.1.47
> PING 192.168.1.47 (192.168.1.47) 56(84) bytes of data.
> ^C
> --- 192.168.1.47 ping statistics ---
> 3 packets transmitted, 0 received, 100% packet loss, time 120ms
> 
> I have tried to revert the bad commit directly in v6.0-rc1 but
> conflicts appeared with the git revert command in
> 'kernel/rcu/tasks.h', so I am not sure what I can do now.

I've pinpointed the issue to 23233e577ef973c2c5d0dd757a0a4605e34ecb57 
("net: ethernet: mtk_eth_soc: rely on page_pool for single page 
buffers"). Ethernet works fine after reverting this and newer commits 
for mtk_eth_soc.

Arınç

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 7532 bytes --]

> On 13.09.2022 11:31, Sergio Paracuellos wrote:
> > Hi Lorenzo,
> > 
> > On Tue, Sep 13, 2022 at 5:32 AM Sergio Paracuellos
> > <sergio.paracuellos@gmail.com> wrote:
> > > 
> > > Hi Lorenzo,
> > > 
> > > On Mon, Sep 12, 2022 at 10:30 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> > > > 
> > > > > Hi Lorenzo,
> > > > > 
> > > > > On 12.09.2022 21:01, Lorenzo Bianconi wrote:
> > > > > > > > Ethernet for MT7621 SoCs no longer works after changes introduced to
> > > > > > > > mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
> > > > > > > > sent out from the interface fine but won't be received on the interface.
> > > > > > > > 
> > > > > > > > Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
> > > > > > > > connected to gmac1 of the SoC.
> > > > > > > > 
> > > > > > > > Last working kernel is 5.19. The issue is present on 6.0-rc5.
> > > > > > > > 
> > > > > > > > Arınç
> > > > > > > 
> > > > > > > Hi Arınç,
> > > > > > > 
> > > > > > > thx for testing and reporting the issue. Can you please identify
> > > > > > > the offending commit running git bisect?
> > > > > > > 
> > > > > > > Regards,
> > > > > > > Lorenzo
> > > > > > 
> > > > > > Hi Arınç,
> > > > > > 
> > > > > > just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
> > > > > > OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
> > > > > > provide more details about your development board/environment?
> > > > > 
> > > > > I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's gnubee-tools
> > > > > which makes an image with filesystem and any Linux kernel of choice with
> > > > > slight modifications (maybe not at all) on the kernel.
> > > > > 
> > > > > https://github.com/neilbrown/gnubee-tools
> > > > > 
> > > > > Sergio experiences the same problem on GB-PC1.
> > > > 
> > > > ack, can you please run git bisect in order to identify the offending commit?
> > > > What is the latest kernel version that is working properly? 5.19.8?
> > > 
> > > I'll try to get time today to properly bisect and identify the
> > > offending commit. I get a working platform with 5.19.8, yes but with
> > > v6-rc-1 my network is totally broken.
> > 
> > + [cc: Paul E. McKenney <paulmck@kernel.org> as commit author]
> > 
> > Ok, so I have bisected the issue to:
> > 1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more patient
> > for RCU Tasks boot-time testing
> > 
> > This is the complete bisect log:
> > 
> > $ git bisect log
> > git bisect start
> > # good: [70cb6afe0e2ff1b7854d840978b1849bffb3ed21] Linux 5.19.8
> > git bisect good 70cb6afe0e2ff1b7854d840978b1849bffb3ed21
> > # bad: [568035b01cfb107af8d2e4bd2fb9aea22cf5b868] Linux 6.0-rc1
> > git bisect bad 568035b01cfb107af8d2e4bd2fb9aea22cf5b868
> > # good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19
> > git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd
> > # bad: [b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1] Merge tag
> > 'drm-next-2022-08-03' of git://anongit.freedesktop.org/drm/drm
> > git bisect bad b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1
> > # bad: [526942b8134cc34d25d27f95dfff98b8ce2f6fcd] Merge tag
> > 'ata-5.20-rc1' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
> > git bisect bad 526942b8134cc34d25d27f95dfff98b8ce2f6fcd
> > # good: [2e7a95156d64667a8ded606829d57c6fc92e41df] Merge tag
> > 'regmap-v5.20' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
> > git bisect good 2e7a95156d64667a8ded606829d57c6fc92e41df
> > # good: [c013d0af81f60cc7dbe357c4e2a925fb6738dbfe] Merge tag
> > 'for-5.20/block-2022-07-29' of git://git.kernel.dk/linux-block
> > git bisect good c013d0af81f60cc7dbe357c4e2a925fb6738dbfe
> > # bad: [aad26f55f47a33d6de3df65f0b18e2886059ed6d] Merge tag 'docs-6.0'
> > of git://git.lwn.net/linux
> > git bisect bad aad26f55f47a33d6de3df65f0b18e2886059ed6d
> > # good: [c2a24a7a036b3bd3a2e6c66730dfc777cae6540a] Merge tag
> > 'v5.20-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
> > git bisect good c2a24a7a036b3bd3a2e6c66730dfc777cae6540a
> > # bad: [34bc7b454dc31f75a0be7ee8ab378135523d7c51] Merge branch
> > 'ctxt.2022.07.05a' into HEAD
> > git bisect bad 34bc7b454dc31f75a0be7ee8ab378135523d7c51
> > # bad: [e72ee5e1a866b85cb6c3d4c80a1125976020a7e8] rcu-tasks: Use
> > delayed_work to delay rcu_tasks_verify_self_tests()
> > git bisect bad e72ee5e1a866b85cb6c3d4c80a1125976020a7e8
> > # good: [f90f19da88bfe32dd1fdfd104de4c0526a3be701] rcu-tasks: Make RCU
> > Tasks Trace stall warning handle idle offline tasks
> > git bisect good f90f19da88bfe32dd1fdfd104de4c0526a3be701
> > # good: [dc7d54b45170e1e3ced9f86718aa4274fd727790] rcu-tasks: Pull in
> > tasks blocked within RCU Tasks Trace readers
> > git bisect good dc7d54b45170e1e3ced9f86718aa4274fd727790
> > # good: [e386b6725798eec07facedf4d4bb710c079fd25c] rcu-tasks:
> > Eliminate RCU Tasks Trace IPIs to online CPUs
> > git bisect good e386b6725798eec07facedf4d4bb710c079fd25c
> > # good: [eea3423b162d5d5cdc08af23e8ee2c2d1134fd07] rcu-tasks: Update comments
> > git bisect good eea3423b162d5d5cdc08af23e8ee2c2d1134fd07
> > # bad: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more
> > patient for RCU Tasks boot-time testing
> > git bisect bad 1cf1144e8473e8c3180ac8b91309e29b6acfd95f
> > # first bad commit: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f]
> > rcu-tasks: Be more patient for RCU Tasks boot-time testing
> > 
> > I don't really understand the relationship with my broken network
> > issue. I am using debian buster and the effect I see is that when the
> > network interface becomes up it hangs waiting for a "task running to
> > raise network interfaces". After about one minute the system boots,
> > the login prompt is shown but I cannot configure at all network
> > interfaces: dhclient does not respond and manually ifconfig does not
> > help also:
> > 
> > root@gnubee:~#
> > root@gnubee:~# dhclient ethblack
> > ^C
> > root@gnubee:~# ifconfig ethblack 192.168.1.101
> > root@gnubee:~# ping 19^C
> > root@gnubee:~# ping 192.168.1.47
> > PING 192.168.1.47 (192.168.1.47) 56(84) bytes of data.
> > ^C
> > --- 192.168.1.47 ping statistics ---
> > 3 packets transmitted, 0 received, 100% packet loss, time 120ms
> > 
> > I have tried to revert the bad commit directly in v6.0-rc1 but
> > conflicts appeared with the git revert command in
> > 'kernel/rcu/tasks.h', so I am not sure what I can do now.
> 
> I've pinpointed the issue to 23233e577ef973c2c5d0dd757a0a4605e34ecb57 ("net:
> ethernet: mtk_eth_soc: rely on page_pool for single page buffers"). Ethernet
> works fine after reverting this and newer commits for mtk_eth_soc.

Hi Arınç,

yes, I run some bisect here as well and this seems the offending commit. Can
you please try the patch below?

Regards,
Lorenzo

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ec617966c953..67a64a2272b9 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1470,7 +1470,7 @@ static void mtk_update_rx_cpu_idx(struct mtk_eth *eth)
 
 static bool mtk_page_pool_enabled(struct mtk_eth *eth)
 {
-	return !eth->hwlro;
+	return MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2);
 }
 
 static struct page_pool *mtk_create_page_pool(struct mtk_eth *eth,

> 
> Arınç

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Sergio Paracuellos]

Hi Lorenzo,

On Tue, Sep 13, 2022 at 12:58 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>
> > On 13.09.2022 11:31, Sergio Paracuellos wrote:
> > > Hi Lorenzo,
> > >
> > > On Tue, Sep 13, 2022 at 5:32 AM Sergio Paracuellos
> > > <sergio.paracuellos@gmail.com> wrote:
> > > >
> > > > Hi Lorenzo,
> > > >
> > > > On Mon, Sep 12, 2022 at 10:30 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> > > > >
> > > > > > Hi Lorenzo,
> > > > > >
> > > > > > On 12.09.2022 21:01, Lorenzo Bianconi wrote:
> > > > > > > > > Ethernet for MT7621 SoCs no longer works after changes introduced to
> > > > > > > > > mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
> > > > > > > > > sent out from the interface fine but won't be received on the interface.
> > > > > > > > >
> > > > > > > > > Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
> > > > > > > > > connected to gmac1 of the SoC.
> > > > > > > > >
> > > > > > > > > Last working kernel is 5.19. The issue is present on 6.0-rc5.
> > > > > > > > >
> > > > > > > > > Arınç
> > > > > > > >
> > > > > > > > Hi Arınç,
> > > > > > > >
> > > > > > > > thx for testing and reporting the issue. Can you please identify
> > > > > > > > the offending commit running git bisect?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Lorenzo
> > > > > > >
> > > > > > > Hi Arınç,
> > > > > > >
> > > > > > > just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
> > > > > > > OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
> > > > > > > provide more details about your development board/environment?
> > > > > >
> > > > > > I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's gnubee-tools
> > > > > > which makes an image with filesystem and any Linux kernel of choice with
> > > > > > slight modifications (maybe not at all) on the kernel.
> > > > > >
> > > > > > https://github.com/neilbrown/gnubee-tools
> > > > > >
> > > > > > Sergio experiences the same problem on GB-PC1.
> > > > >
> > > > > ack, can you please run git bisect in order to identify the offending commit?
> > > > > What is the latest kernel version that is working properly? 5.19.8?
> > > >
> > > > I'll try to get time today to properly bisect and identify the
> > > > offending commit. I get a working platform with 5.19.8, yes but with
> > > > v6-rc-1 my network is totally broken.
> > >
> > > + [cc: Paul E. McKenney <paulmck@kernel.org> as commit author]
> > >
> > > Ok, so I have bisected the issue to:
> > > 1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more patient
> > > for RCU Tasks boot-time testing
> > >
> > > This is the complete bisect log:
> > >
> > > $ git bisect log
> > > git bisect start
> > > # good: [70cb6afe0e2ff1b7854d840978b1849bffb3ed21] Linux 5.19.8
> > > git bisect good 70cb6afe0e2ff1b7854d840978b1849bffb3ed21
> > > # bad: [568035b01cfb107af8d2e4bd2fb9aea22cf5b868] Linux 6.0-rc1
> > > git bisect bad 568035b01cfb107af8d2e4bd2fb9aea22cf5b868
> > > # good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19
> > > git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd
> > > # bad: [b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1] Merge tag
> > > 'drm-next-2022-08-03' of git://anongit.freedesktop.org/drm/drm
> > > git bisect bad b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1
> > > # bad: [526942b8134cc34d25d27f95dfff98b8ce2f6fcd] Merge tag
> > > 'ata-5.20-rc1' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
> > > git bisect bad 526942b8134cc34d25d27f95dfff98b8ce2f6fcd
> > > # good: [2e7a95156d64667a8ded606829d57c6fc92e41df] Merge tag
> > > 'regmap-v5.20' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
> > > git bisect good 2e7a95156d64667a8ded606829d57c6fc92e41df
> > > # good: [c013d0af81f60cc7dbe357c4e2a925fb6738dbfe] Merge tag
> > > 'for-5.20/block-2022-07-29' of git://git.kernel.dk/linux-block
> > > git bisect good c013d0af81f60cc7dbe357c4e2a925fb6738dbfe
> > > # bad: [aad26f55f47a33d6de3df65f0b18e2886059ed6d] Merge tag 'docs-6.0'
> > > of git://git.lwn.net/linux
> > > git bisect bad aad26f55f47a33d6de3df65f0b18e2886059ed6d
> > > # good: [c2a24a7a036b3bd3a2e6c66730dfc777cae6540a] Merge tag
> > > 'v5.20-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
> > > git bisect good c2a24a7a036b3bd3a2e6c66730dfc777cae6540a
> > > # bad: [34bc7b454dc31f75a0be7ee8ab378135523d7c51] Merge branch
> > > 'ctxt.2022.07.05a' into HEAD
> > > git bisect bad 34bc7b454dc31f75a0be7ee8ab378135523d7c51
> > > # bad: [e72ee5e1a866b85cb6c3d4c80a1125976020a7e8] rcu-tasks: Use
> > > delayed_work to delay rcu_tasks_verify_self_tests()
> > > git bisect bad e72ee5e1a866b85cb6c3d4c80a1125976020a7e8
> > > # good: [f90f19da88bfe32dd1fdfd104de4c0526a3be701] rcu-tasks: Make RCU
> > > Tasks Trace stall warning handle idle offline tasks
> > > git bisect good f90f19da88bfe32dd1fdfd104de4c0526a3be701
> > > # good: [dc7d54b45170e1e3ced9f86718aa4274fd727790] rcu-tasks: Pull in
> > > tasks blocked within RCU Tasks Trace readers
> > > git bisect good dc7d54b45170e1e3ced9f86718aa4274fd727790
> > > # good: [e386b6725798eec07facedf4d4bb710c079fd25c] rcu-tasks:
> > > Eliminate RCU Tasks Trace IPIs to online CPUs
> > > git bisect good e386b6725798eec07facedf4d4bb710c079fd25c
> > > # good: [eea3423b162d5d5cdc08af23e8ee2c2d1134fd07] rcu-tasks: Update comments
> > > git bisect good eea3423b162d5d5cdc08af23e8ee2c2d1134fd07
> > > # bad: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more
> > > patient for RCU Tasks boot-time testing
> > > git bisect bad 1cf1144e8473e8c3180ac8b91309e29b6acfd95f
> > > # first bad commit: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f]
> > > rcu-tasks: Be more patient for RCU Tasks boot-time testing
> > >
> > > I don't really understand the relationship with my broken network
> > > issue. I am using debian buster and the effect I see is that when the
> > > network interface becomes up it hangs waiting for a "task running to
> > > raise network interfaces". After about one minute the system boots,
> > > the login prompt is shown but I cannot configure at all network
> > > interfaces: dhclient does not respond and manually ifconfig does not
> > > help also:
> > >
> > > root@gnubee:~#
> > > root@gnubee:~# dhclient ethblack
> > > ^C
> > > root@gnubee:~# ifconfig ethblack 192.168.1.101
> > > root@gnubee:~# ping 19^C
> > > root@gnubee:~# ping 192.168.1.47
> > > PING 192.168.1.47 (192.168.1.47) 56(84) bytes of data.
> > > ^C
> > > --- 192.168.1.47 ping statistics ---
> > > 3 packets transmitted, 0 received, 100% packet loss, time 120ms
> > >
> > > I have tried to revert the bad commit directly in v6.0-rc1 but
> > > conflicts appeared with the git revert command in
> > > 'kernel/rcu/tasks.h', so I am not sure what I can do now.
> >
> > I've pinpointed the issue to 23233e577ef973c2c5d0dd757a0a4605e34ecb57 ("net:
> > ethernet: mtk_eth_soc: rely on page_pool for single page buffers"). Ethernet
> > works fine after reverting this and newer commits for mtk_eth_soc.
>
> Hi Arınç,
>
> yes, I run some bisect here as well and this seems the offending commit. Can
> you please try the patch below?
>
> Regards,
> Lorenzo
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index ec617966c953..67a64a2272b9 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -1470,7 +1470,7 @@ static void mtk_update_rx_cpu_idx(struct mtk_eth *eth)
>
>  static bool mtk_page_pool_enabled(struct mtk_eth *eth)
>  {
> -       return !eth->hwlro;
> +       return MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2);
>  }
>
>  static struct page_pool *mtk_create_page_pool(struct mtk_eth *eth,

I have applied this patch on the top of v6-0-rc5 and the network is
back, so this patch seems to fix the network issue for my GNUBee pC1:

Tested-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>

Thanks,
    Sergio Paracuellos
>
> >
> > Arınç

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Arınç ÜNAL]

On 13.09.2022 14:07, Sergio Paracuellos wrote:
> Hi Lorenzo,
> 
> On Tue, Sep 13, 2022 at 12:58 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>>
>>> On 13.09.2022 11:31, Sergio Paracuellos wrote:
>>>> Hi Lorenzo,
>>>>
>>>> On Tue, Sep 13, 2022 at 5:32 AM Sergio Paracuellos
>>>> <sergio.paracuellos@gmail.com> wrote:
>>>>>
>>>>> Hi Lorenzo,
>>>>>
>>>>> On Mon, Sep 12, 2022 at 10:30 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>>>>>>
>>>>>>> Hi Lorenzo,
>>>>>>>
>>>>>>> On 12.09.2022 21:01, Lorenzo Bianconi wrote:
>>>>>>>>>> Ethernet for MT7621 SoCs no longer works after changes introduced to
>>>>>>>>>> mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
>>>>>>>>>> sent out from the interface fine but won't be received on the interface.
>>>>>>>>>>
>>>>>>>>>> Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
>>>>>>>>>> connected to gmac1 of the SoC.
>>>>>>>>>>
>>>>>>>>>> Last working kernel is 5.19. The issue is present on 6.0-rc5.
>>>>>>>>>>
>>>>>>>>>> Arınç
>>>>>>>>>
>>>>>>>>> Hi Arınç,
>>>>>>>>>
>>>>>>>>> thx for testing and reporting the issue. Can you please identify
>>>>>>>>> the offending commit running git bisect?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Lorenzo
>>>>>>>>
>>>>>>>> Hi Arınç,
>>>>>>>>
>>>>>>>> just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
>>>>>>>> OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
>>>>>>>> provide more details about your development board/environment?
>>>>>>>
>>>>>>> I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's gnubee-tools
>>>>>>> which makes an image with filesystem and any Linux kernel of choice with
>>>>>>> slight modifications (maybe not at all) on the kernel.
>>>>>>>
>>>>>>> https://github.com/neilbrown/gnubee-tools
>>>>>>>
>>>>>>> Sergio experiences the same problem on GB-PC1.
>>>>>>
>>>>>> ack, can you please run git bisect in order to identify the offending commit?
>>>>>> What is the latest kernel version that is working properly? 5.19.8?
>>>>>
>>>>> I'll try to get time today to properly bisect and identify the
>>>>> offending commit. I get a working platform with 5.19.8, yes but with
>>>>> v6-rc-1 my network is totally broken.
>>>>
>>>> + [cc: Paul E. McKenney <paulmck@kernel.org> as commit author]
>>>>
>>>> Ok, so I have bisected the issue to:
>>>> 1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more patient
>>>> for RCU Tasks boot-time testing
>>>>
>>>> This is the complete bisect log:
>>>>
>>>> $ git bisect log
>>>> git bisect start
>>>> # good: [70cb6afe0e2ff1b7854d840978b1849bffb3ed21] Linux 5.19.8
>>>> git bisect good 70cb6afe0e2ff1b7854d840978b1849bffb3ed21
>>>> # bad: [568035b01cfb107af8d2e4bd2fb9aea22cf5b868] Linux 6.0-rc1
>>>> git bisect bad 568035b01cfb107af8d2e4bd2fb9aea22cf5b868
>>>> # good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19
>>>> git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd
>>>> # bad: [b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1] Merge tag
>>>> 'drm-next-2022-08-03' of git://anongit.freedesktop.org/drm/drm
>>>> git bisect bad b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1
>>>> # bad: [526942b8134cc34d25d27f95dfff98b8ce2f6fcd] Merge tag
>>>> 'ata-5.20-rc1' of
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
>>>> git bisect bad 526942b8134cc34d25d27f95dfff98b8ce2f6fcd
>>>> # good: [2e7a95156d64667a8ded606829d57c6fc92e41df] Merge tag
>>>> 'regmap-v5.20' of
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
>>>> git bisect good 2e7a95156d64667a8ded606829d57c6fc92e41df
>>>> # good: [c013d0af81f60cc7dbe357c4e2a925fb6738dbfe] Merge tag
>>>> 'for-5.20/block-2022-07-29' of git://git.kernel.dk/linux-block
>>>> git bisect good c013d0af81f60cc7dbe357c4e2a925fb6738dbfe
>>>> # bad: [aad26f55f47a33d6de3df65f0b18e2886059ed6d] Merge tag 'docs-6.0'
>>>> of git://git.lwn.net/linux
>>>> git bisect bad aad26f55f47a33d6de3df65f0b18e2886059ed6d
>>>> # good: [c2a24a7a036b3bd3a2e6c66730dfc777cae6540a] Merge tag
>>>> 'v5.20-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
>>>> git bisect good c2a24a7a036b3bd3a2e6c66730dfc777cae6540a
>>>> # bad: [34bc7b454dc31f75a0be7ee8ab378135523d7c51] Merge branch
>>>> 'ctxt.2022.07.05a' into HEAD
>>>> git bisect bad 34bc7b454dc31f75a0be7ee8ab378135523d7c51
>>>> # bad: [e72ee5e1a866b85cb6c3d4c80a1125976020a7e8] rcu-tasks: Use
>>>> delayed_work to delay rcu_tasks_verify_self_tests()
>>>> git bisect bad e72ee5e1a866b85cb6c3d4c80a1125976020a7e8
>>>> # good: [f90f19da88bfe32dd1fdfd104de4c0526a3be701] rcu-tasks: Make RCU
>>>> Tasks Trace stall warning handle idle offline tasks
>>>> git bisect good f90f19da88bfe32dd1fdfd104de4c0526a3be701
>>>> # good: [dc7d54b45170e1e3ced9f86718aa4274fd727790] rcu-tasks: Pull in
>>>> tasks blocked within RCU Tasks Trace readers
>>>> git bisect good dc7d54b45170e1e3ced9f86718aa4274fd727790
>>>> # good: [e386b6725798eec07facedf4d4bb710c079fd25c] rcu-tasks:
>>>> Eliminate RCU Tasks Trace IPIs to online CPUs
>>>> git bisect good e386b6725798eec07facedf4d4bb710c079fd25c
>>>> # good: [eea3423b162d5d5cdc08af23e8ee2c2d1134fd07] rcu-tasks: Update comments
>>>> git bisect good eea3423b162d5d5cdc08af23e8ee2c2d1134fd07
>>>> # bad: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more
>>>> patient for RCU Tasks boot-time testing
>>>> git bisect bad 1cf1144e8473e8c3180ac8b91309e29b6acfd95f
>>>> # first bad commit: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f]
>>>> rcu-tasks: Be more patient for RCU Tasks boot-time testing
>>>>
>>>> I don't really understand the relationship with my broken network
>>>> issue. I am using debian buster and the effect I see is that when the
>>>> network interface becomes up it hangs waiting for a "task running to
>>>> raise network interfaces". After about one minute the system boots,
>>>> the login prompt is shown but I cannot configure at all network
>>>> interfaces: dhclient does not respond and manually ifconfig does not
>>>> help also:
>>>>
>>>> root@gnubee:~#
>>>> root@gnubee:~# dhclient ethblack
>>>> ^C
>>>> root@gnubee:~# ifconfig ethblack 192.168.1.101
>>>> root@gnubee:~# ping 19^C
>>>> root@gnubee:~# ping 192.168.1.47
>>>> PING 192.168.1.47 (192.168.1.47) 56(84) bytes of data.
>>>> ^C
>>>> --- 192.168.1.47 ping statistics ---
>>>> 3 packets transmitted, 0 received, 100% packet loss, time 120ms
>>>>
>>>> I have tried to revert the bad commit directly in v6.0-rc1 but
>>>> conflicts appeared with the git revert command in
>>>> 'kernel/rcu/tasks.h', so I am not sure what I can do now.
>>>
>>> I've pinpointed the issue to 23233e577ef973c2c5d0dd757a0a4605e34ecb57 ("net:
>>> ethernet: mtk_eth_soc: rely on page_pool for single page buffers"). Ethernet
>>> works fine after reverting this and newer commits for mtk_eth_soc.
>>
>> Hi Arınç,
>>
>> yes, I run some bisect here as well and this seems the offending commit. Can
>> you please try the patch below?
>>
>> Regards,
>> Lorenzo
>>
>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> index ec617966c953..67a64a2272b9 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> @@ -1470,7 +1470,7 @@ static void mtk_update_rx_cpu_idx(struct mtk_eth *eth)
>>
>>   static bool mtk_page_pool_enabled(struct mtk_eth *eth)
>>   {
>> -       return !eth->hwlro;
>> +       return MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2);
>>   }
>>
>>   static struct page_pool *mtk_create_page_pool(struct mtk_eth *eth,
> 
> I have applied this patch on the top of v6-0-rc5 and the network is
> back, so this patch seems to fix the network issue for my GNUBee pC1:
> 
> Tested-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>

Can confirm the same behaviour on my GB-PC2.

Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>

Arınç

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 9331 bytes --]

> On 13.09.2022 14:07, Sergio Paracuellos wrote:
> > Hi Lorenzo,
> > 
> > On Tue, Sep 13, 2022 at 12:58 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> > > 
> > > > On 13.09.2022 11:31, Sergio Paracuellos wrote:
> > > > > Hi Lorenzo,
> > > > > 
> > > > > On Tue, Sep 13, 2022 at 5:32 AM Sergio Paracuellos
> > > > > <sergio.paracuellos@gmail.com> wrote:
> > > > > > 
> > > > > > Hi Lorenzo,
> > > > > > 
> > > > > > On Mon, Sep 12, 2022 at 10:30 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> > > > > > > 
> > > > > > > > Hi Lorenzo,
> > > > > > > > 
> > > > > > > > On 12.09.2022 21:01, Lorenzo Bianconi wrote:
> > > > > > > > > > > Ethernet for MT7621 SoCs no longer works after changes introduced to
> > > > > > > > > > > mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
> > > > > > > > > > > sent out from the interface fine but won't be received on the interface.
> > > > > > > > > > > 
> > > > > > > > > > > Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
> > > > > > > > > > > connected to gmac1 of the SoC.
> > > > > > > > > > > 
> > > > > > > > > > > Last working kernel is 5.19. The issue is present on 6.0-rc5.
> > > > > > > > > > > 
> > > > > > > > > > > Arınç
> > > > > > > > > > 
> > > > > > > > > > Hi Arınç,
> > > > > > > > > > 
> > > > > > > > > > thx for testing and reporting the issue. Can you please identify
> > > > > > > > > > the offending commit running git bisect?
> > > > > > > > > > 
> > > > > > > > > > Regards,
> > > > > > > > > > Lorenzo
> > > > > > > > > 
> > > > > > > > > Hi Arınç,
> > > > > > > > > 
> > > > > > > > > just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
> > > > > > > > > OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
> > > > > > > > > provide more details about your development board/environment?
> > > > > > > > 
> > > > > > > > I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's gnubee-tools
> > > > > > > > which makes an image with filesystem and any Linux kernel of choice with
> > > > > > > > slight modifications (maybe not at all) on the kernel.
> > > > > > > > 
> > > > > > > > https://github.com/neilbrown/gnubee-tools
> > > > > > > > 
> > > > > > > > Sergio experiences the same problem on GB-PC1.
> > > > > > > 
> > > > > > > ack, can you please run git bisect in order to identify the offending commit?
> > > > > > > What is the latest kernel version that is working properly? 5.19.8?
> > > > > > 
> > > > > > I'll try to get time today to properly bisect and identify the
> > > > > > offending commit. I get a working platform with 5.19.8, yes but with
> > > > > > v6-rc-1 my network is totally broken.
> > > > > 
> > > > > + [cc: Paul E. McKenney <paulmck@kernel.org> as commit author]
> > > > > 
> > > > > Ok, so I have bisected the issue to:
> > > > > 1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more patient
> > > > > for RCU Tasks boot-time testing
> > > > > 
> > > > > This is the complete bisect log:
> > > > > 
> > > > > $ git bisect log
> > > > > git bisect start
> > > > > # good: [70cb6afe0e2ff1b7854d840978b1849bffb3ed21] Linux 5.19.8
> > > > > git bisect good 70cb6afe0e2ff1b7854d840978b1849bffb3ed21
> > > > > # bad: [568035b01cfb107af8d2e4bd2fb9aea22cf5b868] Linux 6.0-rc1
> > > > > git bisect bad 568035b01cfb107af8d2e4bd2fb9aea22cf5b868
> > > > > # good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19
> > > > > git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd
> > > > > # bad: [b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1] Merge tag
> > > > > 'drm-next-2022-08-03' of git://anongit.freedesktop.org/drm/drm
> > > > > git bisect bad b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1
> > > > > # bad: [526942b8134cc34d25d27f95dfff98b8ce2f6fcd] Merge tag
> > > > > 'ata-5.20-rc1' of
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
> > > > > git bisect bad 526942b8134cc34d25d27f95dfff98b8ce2f6fcd
> > > > > # good: [2e7a95156d64667a8ded606829d57c6fc92e41df] Merge tag
> > > > > 'regmap-v5.20' of
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
> > > > > git bisect good 2e7a95156d64667a8ded606829d57c6fc92e41df
> > > > > # good: [c013d0af81f60cc7dbe357c4e2a925fb6738dbfe] Merge tag
> > > > > 'for-5.20/block-2022-07-29' of git://git.kernel.dk/linux-block
> > > > > git bisect good c013d0af81f60cc7dbe357c4e2a925fb6738dbfe
> > > > > # bad: [aad26f55f47a33d6de3df65f0b18e2886059ed6d] Merge tag 'docs-6.0'
> > > > > of git://git.lwn.net/linux
> > > > > git bisect bad aad26f55f47a33d6de3df65f0b18e2886059ed6d
> > > > > # good: [c2a24a7a036b3bd3a2e6c66730dfc777cae6540a] Merge tag
> > > > > 'v5.20-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
> > > > > git bisect good c2a24a7a036b3bd3a2e6c66730dfc777cae6540a
> > > > > # bad: [34bc7b454dc31f75a0be7ee8ab378135523d7c51] Merge branch
> > > > > 'ctxt.2022.07.05a' into HEAD
> > > > > git bisect bad 34bc7b454dc31f75a0be7ee8ab378135523d7c51
> > > > > # bad: [e72ee5e1a866b85cb6c3d4c80a1125976020a7e8] rcu-tasks: Use
> > > > > delayed_work to delay rcu_tasks_verify_self_tests()
> > > > > git bisect bad e72ee5e1a866b85cb6c3d4c80a1125976020a7e8
> > > > > # good: [f90f19da88bfe32dd1fdfd104de4c0526a3be701] rcu-tasks: Make RCU
> > > > > Tasks Trace stall warning handle idle offline tasks
> > > > > git bisect good f90f19da88bfe32dd1fdfd104de4c0526a3be701
> > > > > # good: [dc7d54b45170e1e3ced9f86718aa4274fd727790] rcu-tasks: Pull in
> > > > > tasks blocked within RCU Tasks Trace readers
> > > > > git bisect good dc7d54b45170e1e3ced9f86718aa4274fd727790
> > > > > # good: [e386b6725798eec07facedf4d4bb710c079fd25c] rcu-tasks:
> > > > > Eliminate RCU Tasks Trace IPIs to online CPUs
> > > > > git bisect good e386b6725798eec07facedf4d4bb710c079fd25c
> > > > > # good: [eea3423b162d5d5cdc08af23e8ee2c2d1134fd07] rcu-tasks: Update comments
> > > > > git bisect good eea3423b162d5d5cdc08af23e8ee2c2d1134fd07
> > > > > # bad: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more
> > > > > patient for RCU Tasks boot-time testing
> > > > > git bisect bad 1cf1144e8473e8c3180ac8b91309e29b6acfd95f
> > > > > # first bad commit: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f]
> > > > > rcu-tasks: Be more patient for RCU Tasks boot-time testing
> > > > > 
> > > > > I don't really understand the relationship with my broken network
> > > > > issue. I am using debian buster and the effect I see is that when the
> > > > > network interface becomes up it hangs waiting for a "task running to
> > > > > raise network interfaces". After about one minute the system boots,
> > > > > the login prompt is shown but I cannot configure at all network
> > > > > interfaces: dhclient does not respond and manually ifconfig does not
> > > > > help also:
> > > > > 
> > > > > root@gnubee:~#
> > > > > root@gnubee:~# dhclient ethblack
> > > > > ^C
> > > > > root@gnubee:~# ifconfig ethblack 192.168.1.101
> > > > > root@gnubee:~# ping 19^C
> > > > > root@gnubee:~# ping 192.168.1.47
> > > > > PING 192.168.1.47 (192.168.1.47) 56(84) bytes of data.
> > > > > ^C
> > > > > --- 192.168.1.47 ping statistics ---
> > > > > 3 packets transmitted, 0 received, 100% packet loss, time 120ms
> > > > > 
> > > > > I have tried to revert the bad commit directly in v6.0-rc1 but
> > > > > conflicts appeared with the git revert command in
> > > > > 'kernel/rcu/tasks.h', so I am not sure what I can do now.
> > > > 
> > > > I've pinpointed the issue to 23233e577ef973c2c5d0dd757a0a4605e34ecb57 ("net:
> > > > ethernet: mtk_eth_soc: rely on page_pool for single page buffers"). Ethernet
> > > > works fine after reverting this and newer commits for mtk_eth_soc.
> > > 
> > > Hi Arınç,
> > > 
> > > yes, I run some bisect here as well and this seems the offending commit. Can
> > > you please try the patch below?
> > > 
> > > Regards,
> > > Lorenzo
> > > 
> > > diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > index ec617966c953..67a64a2272b9 100644
> > > --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > @@ -1470,7 +1470,7 @@ static void mtk_update_rx_cpu_idx(struct mtk_eth *eth)
> > > 
> > >   static bool mtk_page_pool_enabled(struct mtk_eth *eth)
> > >   {
> > > -       return !eth->hwlro;
> > > +       return MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2);
> > >   }
> > > 
> > >   static struct page_pool *mtk_create_page_pool(struct mtk_eth *eth,
> > 
> > I have applied this patch on the top of v6-0-rc5 and the network is
> > back, so this patch seems to fix the network issue for my GNUBee pC1:
> > 
> > Tested-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
> 
> Can confirm the same behaviour on my GB-PC2.
> 
> Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>

I debugged a bit more the problem and the issue is due to a 2 bytes alignment
introduced by mt7621 on packet data.
Since mt7621 is a low-end SoC and I do not have other SoCs for testing, I will
enable xdp support just for MT7986 for the moment. Thanks a lot for reporting the
issue and for testing.

Regards,
Lorenzo

> 
> Arınç

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Sergio Paracuellos]

On Tue, Sep 13, 2022 at 2:23 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>
> > On 13.09.2022 14:07, Sergio Paracuellos wrote:
> > > Hi Lorenzo,
> > >
> > > On Tue, Sep 13, 2022 at 12:58 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> > > >
> > > > > On 13.09.2022 11:31, Sergio Paracuellos wrote:
> > > > > > Hi Lorenzo,
> > > > > >
> > > > > > On Tue, Sep 13, 2022 at 5:32 AM Sergio Paracuellos
> > > > > > <sergio.paracuellos@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Lorenzo,
> > > > > > >
> > > > > > > On Mon, Sep 12, 2022 at 10:30 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> > > > > > > >
> > > > > > > > > Hi Lorenzo,
> > > > > > > > >
> > > > > > > > > On 12.09.2022 21:01, Lorenzo Bianconi wrote:
> > > > > > > > > > > > Ethernet for MT7621 SoCs no longer works after changes introduced to
> > > > > > > > > > > > mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
> > > > > > > > > > > > sent out from the interface fine but won't be received on the interface.
> > > > > > > > > > > >
> > > > > > > > > > > > Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
> > > > > > > > > > > > connected to gmac1 of the SoC.
> > > > > > > > > > > >
> > > > > > > > > > > > Last working kernel is 5.19. The issue is present on 6.0-rc5.
> > > > > > > > > > > >
> > > > > > > > > > > > Arınç
> > > > > > > > > > >
> > > > > > > > > > > Hi Arınç,
> > > > > > > > > > >
> > > > > > > > > > > thx for testing and reporting the issue. Can you please identify
> > > > > > > > > > > the offending commit running git bisect?
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > Lorenzo
> > > > > > > > > >
> > > > > > > > > > Hi Arınç,
> > > > > > > > > >
> > > > > > > > > > just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
> > > > > > > > > > OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
> > > > > > > > > > provide more details about your development board/environment?
> > > > > > > > >
> > > > > > > > > I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's gnubee-tools
> > > > > > > > > which makes an image with filesystem and any Linux kernel of choice with
> > > > > > > > > slight modifications (maybe not at all) on the kernel.
> > > > > > > > >
> > > > > > > > > https://github.com/neilbrown/gnubee-tools
> > > > > > > > >
> > > > > > > > > Sergio experiences the same problem on GB-PC1.
> > > > > > > >
> > > > > > > > ack, can you please run git bisect in order to identify the offending commit?
> > > > > > > > What is the latest kernel version that is working properly? 5.19.8?
> > > > > > >
> > > > > > > I'll try to get time today to properly bisect and identify the
> > > > > > > offending commit. I get a working platform with 5.19.8, yes but with
> > > > > > > v6-rc-1 my network is totally broken.
> > > > > >
> > > > > > + [cc: Paul E. McKenney <paulmck@kernel.org> as commit author]
> > > > > >
> > > > > > Ok, so I have bisected the issue to:
> > > > > > 1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more patient
> > > > > > for RCU Tasks boot-time testing
> > > > > >
> > > > > > This is the complete bisect log:
> > > > > >
> > > > > > $ git bisect log
> > > > > > git bisect start
> > > > > > # good: [70cb6afe0e2ff1b7854d840978b1849bffb3ed21] Linux 5.19.8
> > > > > > git bisect good 70cb6afe0e2ff1b7854d840978b1849bffb3ed21
> > > > > > # bad: [568035b01cfb107af8d2e4bd2fb9aea22cf5b868] Linux 6.0-rc1
> > > > > > git bisect bad 568035b01cfb107af8d2e4bd2fb9aea22cf5b868
> > > > > > # good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19
> > > > > > git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd
> > > > > > # bad: [b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1] Merge tag
> > > > > > 'drm-next-2022-08-03' of git://anongit.freedesktop.org/drm/drm
> > > > > > git bisect bad b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1
> > > > > > # bad: [526942b8134cc34d25d27f95dfff98b8ce2f6fcd] Merge tag
> > > > > > 'ata-5.20-rc1' of
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
> > > > > > git bisect bad 526942b8134cc34d25d27f95dfff98b8ce2f6fcd
> > > > > > # good: [2e7a95156d64667a8ded606829d57c6fc92e41df] Merge tag
> > > > > > 'regmap-v5.20' of
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
> > > > > > git bisect good 2e7a95156d64667a8ded606829d57c6fc92e41df
> > > > > > # good: [c013d0af81f60cc7dbe357c4e2a925fb6738dbfe] Merge tag
> > > > > > 'for-5.20/block-2022-07-29' of git://git.kernel.dk/linux-block
> > > > > > git bisect good c013d0af81f60cc7dbe357c4e2a925fb6738dbfe
> > > > > > # bad: [aad26f55f47a33d6de3df65f0b18e2886059ed6d] Merge tag 'docs-6.0'
> > > > > > of git://git.lwn.net/linux
> > > > > > git bisect bad aad26f55f47a33d6de3df65f0b18e2886059ed6d
> > > > > > # good: [c2a24a7a036b3bd3a2e6c66730dfc777cae6540a] Merge tag
> > > > > > 'v5.20-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
> > > > > > git bisect good c2a24a7a036b3bd3a2e6c66730dfc777cae6540a
> > > > > > # bad: [34bc7b454dc31f75a0be7ee8ab378135523d7c51] Merge branch
> > > > > > 'ctxt.2022.07.05a' into HEAD
> > > > > > git bisect bad 34bc7b454dc31f75a0be7ee8ab378135523d7c51
> > > > > > # bad: [e72ee5e1a866b85cb6c3d4c80a1125976020a7e8] rcu-tasks: Use
> > > > > > delayed_work to delay rcu_tasks_verify_self_tests()
> > > > > > git bisect bad e72ee5e1a866b85cb6c3d4c80a1125976020a7e8
> > > > > > # good: [f90f19da88bfe32dd1fdfd104de4c0526a3be701] rcu-tasks: Make RCU
> > > > > > Tasks Trace stall warning handle idle offline tasks
> > > > > > git bisect good f90f19da88bfe32dd1fdfd104de4c0526a3be701
> > > > > > # good: [dc7d54b45170e1e3ced9f86718aa4274fd727790] rcu-tasks: Pull in
> > > > > > tasks blocked within RCU Tasks Trace readers
> > > > > > git bisect good dc7d54b45170e1e3ced9f86718aa4274fd727790
> > > > > > # good: [e386b6725798eec07facedf4d4bb710c079fd25c] rcu-tasks:
> > > > > > Eliminate RCU Tasks Trace IPIs to online CPUs
> > > > > > git bisect good e386b6725798eec07facedf4d4bb710c079fd25c
> > > > > > # good: [eea3423b162d5d5cdc08af23e8ee2c2d1134fd07] rcu-tasks: Update comments
> > > > > > git bisect good eea3423b162d5d5cdc08af23e8ee2c2d1134fd07
> > > > > > # bad: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more
> > > > > > patient for RCU Tasks boot-time testing
> > > > > > git bisect bad 1cf1144e8473e8c3180ac8b91309e29b6acfd95f
> > > > > > # first bad commit: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f]
> > > > > > rcu-tasks: Be more patient for RCU Tasks boot-time testing
> > > > > >
> > > > > > I don't really understand the relationship with my broken network
> > > > > > issue. I am using debian buster and the effect I see is that when the
> > > > > > network interface becomes up it hangs waiting for a "task running to
> > > > > > raise network interfaces". After about one minute the system boots,
> > > > > > the login prompt is shown but I cannot configure at all network
> > > > > > interfaces: dhclient does not respond and manually ifconfig does not
> > > > > > help also:
> > > > > >
> > > > > > root@gnubee:~#
> > > > > > root@gnubee:~# dhclient ethblack
> > > > > > ^C
> > > > > > root@gnubee:~# ifconfig ethblack 192.168.1.101
> > > > > > root@gnubee:~# ping 19^C
> > > > > > root@gnubee:~# ping 192.168.1.47
> > > > > > PING 192.168.1.47 (192.168.1.47) 56(84) bytes of data.
> > > > > > ^C
> > > > > > --- 192.168.1.47 ping statistics ---
> > > > > > 3 packets transmitted, 0 received, 100% packet loss, time 120ms
> > > > > >
> > > > > > I have tried to revert the bad commit directly in v6.0-rc1 but
> > > > > > conflicts appeared with the git revert command in
> > > > > > 'kernel/rcu/tasks.h', so I am not sure what I can do now.
> > > > >
> > > > > I've pinpointed the issue to 23233e577ef973c2c5d0dd757a0a4605e34ecb57 ("net:
> > > > > ethernet: mtk_eth_soc: rely on page_pool for single page buffers"). Ethernet
> > > > > works fine after reverting this and newer commits for mtk_eth_soc.
> > > >
> > > > Hi Arınç,
> > > >
> > > > yes, I run some bisect here as well and this seems the offending commit. Can
> > > > you please try the patch below?
> > > >
> > > > Regards,
> > > > Lorenzo
> > > >
> > > > diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > > index ec617966c953..67a64a2272b9 100644
> > > > --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > > +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > > @@ -1470,7 +1470,7 @@ static void mtk_update_rx_cpu_idx(struct mtk_eth *eth)
> > > >
> > > >   static bool mtk_page_pool_enabled(struct mtk_eth *eth)
> > > >   {
> > > > -       return !eth->hwlro;
> > > > +       return MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2);
> > > >   }
> > > >
> > > >   static struct page_pool *mtk_create_page_pool(struct mtk_eth *eth,
> > >
> > > I have applied this patch on the top of v6-0-rc5 and the network is
> > > back, so this patch seems to fix the network issue for my GNUBee pC1:
> > >
> > > Tested-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
> >
> > Can confirm the same behaviour on my GB-PC2.
> >
> > Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>
> I debugged a bit more the problem and the issue is due to a 2 bytes alignment
> introduced by mt7621 on packet data.
> Since mt7621 is a low-end SoC and I do not have other SoCs for testing, I will
> enable xdp support just for MT7986 for the moment. Thanks a lot for reporting the
> issue and for testing.
>

Thanks to you for such a quick fix. Feel free to send us whatever
patch you need to test on mt7621.

Best regards,
    Sergio Paracuellos

> Regards,
> Lorenzo
>
> >
> > Arınç

Re: mtk_eth_soc for mt7621 won't work after 6.0-rc1

[Sergio Paracuellos]

On Tue, Sep 13, 2022 at 12:42 PM Arınç ÜNAL <arinc.unal@arinc9.com> wrote:
>
> On 13.09.2022 11:31, Sergio Paracuellos wrote:
> > Hi Lorenzo,
> >
> > On Tue, Sep 13, 2022 at 5:32 AM Sergio Paracuellos
> > <sergio.paracuellos@gmail.com> wrote:
> >>
> >> Hi Lorenzo,
> >>
> >> On Mon, Sep 12, 2022 at 10:30 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> >>>
> >>>> Hi Lorenzo,
> >>>>
> >>>> On 12.09.2022 21:01, Lorenzo Bianconi wrote:
> >>>>>>> Ethernet for MT7621 SoCs no longer works after changes introduced to
> >>>>>>> mtk_eth_soc with 6.0-rc1. Ethernet interfaces initialise fine. Packets are
> >>>>>>> sent out from the interface fine but won't be received on the interface.
> >>>>>>>
> >>>>>>> Tested with MT7530 DSA switch connected to gmac0 and ICPlus IP1001 PHY
> >>>>>>> connected to gmac1 of the SoC.
> >>>>>>>
> >>>>>>> Last working kernel is 5.19. The issue is present on 6.0-rc5.
> >>>>>>>
> >>>>>>> Arınç
> >>>>>>
> >>>>>> Hi Arınç,
> >>>>>>
> >>>>>> thx for testing and reporting the issue. Can you please identify
> >>>>>> the offending commit running git bisect?
> >>>>>>
> >>>>>> Regards,
> >>>>>> Lorenzo
> >>>>>
> >>>>> Hi Arınç,
> >>>>>
> >>>>> just a small update. I tested a mt7621 based board (Buffalo WSR-1166DHP) with
> >>>>> OpenWrt master + my mtk_eth_soc series and it works fine. Can you please
> >>>>> provide more details about your development board/environment?
> >>>>
> >>>> I've got a GB-PC2, Sergio has got a GB-PC1. We both use Neil's gnubee-tools
> >>>> which makes an image with filesystem and any Linux kernel of choice with
> >>>> slight modifications (maybe not at all) on the kernel.
> >>>>
> >>>> https://github.com/neilbrown/gnubee-tools
> >>>>
> >>>> Sergio experiences the same problem on GB-PC1.
> >>>
> >>> ack, can you please run git bisect in order to identify the offending commit?
> >>> What is the latest kernel version that is working properly? 5.19.8?
> >>
> >> I'll try to get time today to properly bisect and identify the
> >> offending commit. I get a working platform with 5.19.8, yes but with
> >> v6-rc-1 my network is totally broken.
> >
> > + [cc: Paul E. McKenney <paulmck@kernel.org> as commit author]
> >
> > Ok, so I have bisected the issue to:
> > 1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more patient
> > for RCU Tasks boot-time testing
> >
> > This is the complete bisect log:
> >
> > $ git bisect log
> > git bisect start
> > # good: [70cb6afe0e2ff1b7854d840978b1849bffb3ed21] Linux 5.19.8
> > git bisect good 70cb6afe0e2ff1b7854d840978b1849bffb3ed21
> > # bad: [568035b01cfb107af8d2e4bd2fb9aea22cf5b868] Linux 6.0-rc1
> > git bisect bad 568035b01cfb107af8d2e4bd2fb9aea22cf5b868
> > # good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19
> > git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd
> > # bad: [b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1] Merge tag
> > 'drm-next-2022-08-03' of git://anongit.freedesktop.org/drm/drm
> > git bisect bad b44f2fd87919b5ae6e1756d4c7ba2cbba22238e1
> > # bad: [526942b8134cc34d25d27f95dfff98b8ce2f6fcd] Merge tag
> > 'ata-5.20-rc1' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
> > git bisect bad 526942b8134cc34d25d27f95dfff98b8ce2f6fcd
> > # good: [2e7a95156d64667a8ded606829d57c6fc92e41df] Merge tag
> > 'regmap-v5.20' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
> > git bisect good 2e7a95156d64667a8ded606829d57c6fc92e41df
> > # good: [c013d0af81f60cc7dbe357c4e2a925fb6738dbfe] Merge tag
> > 'for-5.20/block-2022-07-29' of git://git.kernel.dk/linux-block
> > git bisect good c013d0af81f60cc7dbe357c4e2a925fb6738dbfe
> > # bad: [aad26f55f47a33d6de3df65f0b18e2886059ed6d] Merge tag 'docs-6.0'
> > of git://git.lwn.net/linux
> > git bisect bad aad26f55f47a33d6de3df65f0b18e2886059ed6d
> > # good: [c2a24a7a036b3bd3a2e6c66730dfc777cae6540a] Merge tag
> > 'v5.20-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
> > git bisect good c2a24a7a036b3bd3a2e6c66730dfc777cae6540a
> > # bad: [34bc7b454dc31f75a0be7ee8ab378135523d7c51] Merge branch
> > 'ctxt.2022.07.05a' into HEAD
> > git bisect bad 34bc7b454dc31f75a0be7ee8ab378135523d7c51
> > # bad: [e72ee5e1a866b85cb6c3d4c80a1125976020a7e8] rcu-tasks: Use
> > delayed_work to delay rcu_tasks_verify_self_tests()
> > git bisect bad e72ee5e1a866b85cb6c3d4c80a1125976020a7e8
> > # good: [f90f19da88bfe32dd1fdfd104de4c0526a3be701] rcu-tasks: Make RCU
> > Tasks Trace stall warning handle idle offline tasks
> > git bisect good f90f19da88bfe32dd1fdfd104de4c0526a3be701
> > # good: [dc7d54b45170e1e3ced9f86718aa4274fd727790] rcu-tasks: Pull in
> > tasks blocked within RCU Tasks Trace readers
> > git bisect good dc7d54b45170e1e3ced9f86718aa4274fd727790
> > # good: [e386b6725798eec07facedf4d4bb710c079fd25c] rcu-tasks:
> > Eliminate RCU Tasks Trace IPIs to online CPUs
> > git bisect good e386b6725798eec07facedf4d4bb710c079fd25c
> > # good: [eea3423b162d5d5cdc08af23e8ee2c2d1134fd07] rcu-tasks: Update comments
> > git bisect good eea3423b162d5d5cdc08af23e8ee2c2d1134fd07
> > # bad: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f] rcu-tasks: Be more
> > patient for RCU Tasks boot-time testing
> > git bisect bad 1cf1144e8473e8c3180ac8b91309e29b6acfd95f
> > # first bad commit: [1cf1144e8473e8c3180ac8b91309e29b6acfd95f]
> > rcu-tasks: Be more patient for RCU Tasks boot-time testing
> >
> > I don't really understand the relationship with my broken network
> > issue. I am using debian buster and the effect I see is that when the
> > network interface becomes up it hangs waiting for a "task running to
> > raise network interfaces". After about one minute the system boots,
> > the login prompt is shown but I cannot configure at all network
> > interfaces: dhclient does not respond and manually ifconfig does not
> > help also:
> >
> > root@gnubee:~#
> > root@gnubee:~# dhclient ethblack
> > ^C
> > root@gnubee:~# ifconfig ethblack 192.168.1.101
> > root@gnubee:~# ping 19^C
> > root@gnubee:~# ping 192.168.1.47
> > PING 192.168.1.47 (192.168.1.47) 56(84) bytes of data.
> > ^C
> > --- 192.168.1.47 ping statistics ---
> > 3 packets transmitted, 0 received, 100% packet loss, time 120ms
> >
> > I have tried to revert the bad commit directly in v6.0-rc1 but
> > conflicts appeared with the git revert command in
> > 'kernel/rcu/tasks.h', so I am not sure what I can do now.
>
> I've pinpointed the issue to 23233e577ef973c2c5d0dd757a0a4605e34ecb57
> ("net: ethernet: mtk_eth_soc: rely on page_pool for single page
> buffers"). Ethernet works fine after reverting this and newer commits
> for mtk_eth_soc.

This has more sense. I don't know what might have happened with my
bisection, so sorry for the noise.

Best regards,
    Sergio Paracuellos
>
> Arınç

gmac1 issues with mtk_eth_soc & port 5 issues with MT7530 DSA driver

[Arınç ÜNAL]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

I'd like to post a few more issues I stumbled upon on mtk_eth_soc and 
MT7530 DSA drivers. All of this is tested on vanilla 6.0-rc5 on GB-PC2.

## MT7621 Ethernet gmac1 won’t work when gmac1 is used as DSA master for 
MT7530 switch

There’s recently been changes on the MT7530 DSA driver by Frank to 
support using port 5 as a CPU port.

The MT7530 switch’s port 5 is wired to the MT7621 SoC’s gmac1.

Master eth1 and slave interfaces initialise fine. Packets are sent out 
from eth1 fine but won't be received on eth1.

This issue existed before Lorenzo’s changes on 6.0-rc1.

I’m not sure if this is an issue with mtk_eth_soc or the MT7530 DSA driver.

---

## MT7530 sends malformed packets to/from CPU at port 5 when port 6 is 
not defined on devicetree

In this case, I can see eth1 receiving traffic as the receive counter on 
ifconfig goes up with the ARP packets sent to the mt7621 CPU.

I see the mt7621 CPU not responding to the ARP packets (no malformed 
packets or anything), which likely means ARP packets received on the 
mt7621 CPU side are also malformed.

I think this confirms that the above issue is related to the MT7530 DSA 
driver as I can see eth1 receiving traffic in this case.

Packet capture of the malformed packets are in the attachments.

---

## MT7621 Ethernet gmac1 won’t work when gmac0 is not defined on devicetree

eth0 interface is initalised even though it’s not defined on the 
devicetree, eth1 interface is not created at all.

This is likely not related to the MT7530 DSA driver.

Arınç

[-- Attachment #2: malformed.pcapng --]
[-- Type: application/x-pcapng, Size: 2968 bytes --]

Re: gmac1 issues with mtk_eth_soc & port 5 issues with MT7530 DSA driver

[Frank Wunderlich]

Am 13. September 2022 14:54:20 MESZ schrieb "Arınç ÜNAL" <arinc.unal@arinc9.com>:
>I'd like to post a few more issues I stumbled upon on mtk_eth_soc and MT7530 DSA drivers. All of this is tested on vanilla 6.0-rc5 on GB-PC2.
>
>## MT7621 Ethernet gmac1 won’t work when gmac1 is used as DSA master for MT7530 switch
>
>There’s recently been changes on the MT7530 DSA driver by Frank to support using port 5 as a CPU port.
>
>The MT7530 switch’s port 5 is wired to the MT7621 SoC’s gmac1.
>
>Master eth1 and slave interfaces initialise fine. Packets are sent out from eth1 fine but won't be received on eth1.
>
>This issue existed before Lorenzo’s changes on 6.0-rc1.
>
>I’m not sure if this is an issue with mtk_eth_soc or the MT7530 DSA driver.
>
>---
>
>## MT7530 sends malformed packets to/from CPU at port 5 when port 6 is not defined on devicetree
>
>In this case, I can see eth1 receiving traffic as the receive counter on ifconfig goes up with the ARP packets sent to the mt7621 CPU.
>
>I see the mt7621 CPU not responding to the ARP packets (no malformed packets or anything), which likely means ARP packets received on the mt7621 CPU side are also malformed.
>
>I think this confirms that the above issue is related to the MT7530 DSA driver as I can see eth1 receiving traffic in this case.
>
>Packet capture of the malformed packets are in the attachments.
>
>---
>
>## MT7621 Ethernet gmac1 won’t work when gmac0 is not defined on devicetree
>
>eth0 interface is initalised even though it’s not defined on the devicetree, eth1 interface is not created at all.
>
>This is likely not related to the MT7530 DSA driver.
>
>Arınç
There are some patches fixing ethernet and dsa driver for getting sfps to work.

https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=9469ba3568d7d9de31dc63de5269c848a1cc1dc7

And on dsa side imho only to support sfp

https://github.com/openwrt/openwrt/commit/bd6783f4fb8f6171927e9067c0005a6d69fc13fe

Hope the first patches help you with your issue

regards Frank

Re: gmac1 issues with mtk_eth_soc & port 5 issues with MT7530 DSA driver

[Arınç ÜNAL]

On 13.09.2022 16:45, Frank Wunderlich wrote:
> Am 13. September 2022 14:54:20 MESZ schrieb "Arınç ÜNAL" <arinc.unal@arinc9.com>:
>> I'd like to post a few more issues I stumbled upon on mtk_eth_soc and MT7530 DSA drivers. All of this is tested on vanilla 6.0-rc5 on GB-PC2.
>>
>> ## MT7621 Ethernet gmac1 won’t work when gmac1 is used as DSA master for MT7530 switch
>>
>> There’s recently been changes on the MT7530 DSA driver by Frank to support using port 5 as a CPU port.
>>
>> The MT7530 switch’s port 5 is wired to the MT7621 SoC’s gmac1.
>>
>> Master eth1 and slave interfaces initialise fine. Packets are sent out from eth1 fine but won't be received on eth1.
>>
>> This issue existed before Lorenzo’s changes on 6.0-rc1.
>>
>> I’m not sure if this is an issue with mtk_eth_soc or the MT7530 DSA driver.
>>
>> ---
>>
>> ## MT7530 sends malformed packets to/from CPU at port 5 when port 6 is not defined on devicetree
>>
>> In this case, I can see eth1 receiving traffic as the receive counter on ifconfig goes up with the ARP packets sent to the mt7621 CPU.
>>
>> I see the mt7621 CPU not responding to the ARP packets (no malformed packets or anything), which likely means ARP packets received on the mt7621 CPU side are also malformed.
>>
>> I think this confirms that the above issue is related to the MT7530 DSA driver as I can see eth1 receiving traffic in this case.
>>
>> Packet capture of the malformed packets are in the attachments.
>>
>> ---
>>
>> ## MT7621 Ethernet gmac1 won’t work when gmac0 is not defined on devicetree
>>
>> eth0 interface is initalised even though it’s not defined on the devicetree, eth1 interface is not created at all.
>>
>> This is likely not related to the MT7530 DSA driver.
>>
>> Arınç
> There are some patches fixing ethernet and dsa driver for getting sfps to work.
> 
> https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=9469ba3568d7d9de31dc63de5269c848a1cc1dc7
> 
> And on dsa side imho only to support sfp
> 
> https://github.com/openwrt/openwrt/commit/bd6783f4fb8f6171927e9067c0005a6d69fc13fe
> 
> Hope the first patches help you with your issue

Thanks for pointing these patches out Frank. I tried these but it didn't 
fix any of the issues I described.

It's been a while since this post. In the meantime, I've gained access 
to a Bananapi BPI-R2 and tested whether the first issue I described 
exists there too. It does. The behaviour on that one was slightly 
different which helped me actually figure out what part of the code 
causes this. I'll send another reply to this post to explain all that.

Arınç

Re: gmac1 issues with mtk_eth_soc & port 5 issues with MT7530 DSA driver

[Arınç ÜNAL]

After testing stuff out, I've got things to share on these issues.

All of this is tested on the current net-next/main on GB-PC2 and Unielec 
U7621-06.

On 13.09.2022 15:54, Arınç ÜNAL wrote:
> I'd like to post a few more issues I stumbled upon on mtk_eth_soc and 
> MT7530 DSA drivers. All of this is tested on vanilla 6.0-rc5 on GB-PC2.
> 
> ## MT7621 Ethernet gmac1 won’t work when gmac1 is used as DSA master for 
> MT7530 switch
> 
> There’s recently been changes on the MT7530 DSA driver by Frank to 
> support using port 5 as a CPU port.
> 
> The MT7530 switch’s port 5 is wired to the MT7621 SoC’s gmac1.
> 
> Master eth1 and slave interfaces initialise fine. Packets are sent out 
> from eth1 fine but won't be received on eth1.
> 
> This issue existed before Lorenzo’s changes on 6.0-rc1.
> 
> I’m not sure if this is an issue with mtk_eth_soc or the MT7530 DSA driver.

Traffic from CPU goes out through DSA slave fine. Traffic from DSA slave 
to CPU reaches, RX bytes go up on eth1, but nothing on tcpdump.

Recently, I tried this on a Bananapi BPI-R2 (MT7623NI SoC). Everything 
works fine after setting up eth0, `ip l set up eth0`. It still works 
after setting down eth0. This makes me believe that, on mtk_eth_soc.c, 
there is code for opening the first MAC, which is actually needed to 
make communication work on all MACs. It should be moved to a more 
generic location where the code will run even when the first MAC is not 
being used.

After fiddling with the MediaTek ethernet driver, I found out that gmac1 
works only when hardware special tag parsing is disabled. This is the 
case for the MT7621A and MT7623NI SoCs.

With Felix's commit 2d7605a729062bb554f03c5983d8cfb8c0b42e9c ("net: 
ethernet: mtk_eth_soc: enable hardware DSA untagging"), hardware special 
tag parsing is disabled only when at least one MAC does not use DSA.

If someone could give me code to test where this function is disabled 
for these two SoCs, I'd appreciate it.

Currently this works:

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 801deac58bf7..3c462179dcf6 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -3241,6 +3241,7 @@ static int mtk_open(struct net_device *dev)
  {
  	struct mtk_mac *mac = netdev_priv(dev);
  	struct mtk_eth *eth = mac->hw;
+	u32 val;
  	int i, err;

  	if (mtk_uses_dsa(dev) && !eth->prog) {
@@ -3258,15 +3259,15 @@ static int mtk_open(struct net_device *dev)
  			md_dst->u.port_info.port_id = i;
  			eth->dsa_meta[i] = md_dst;
  		}
-	} else {
-		/* Hardware special tag parsing needs to be disabled if at least
-		 * one MAC does not use DSA.
-		 */
-		u32 val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
-		val &= ~MTK_CDMP_STAG_EN;
-		mtk_w32(eth, val, MTK_CDMP_IG_CTRL);
  	}

+	/* Hardware special tag parsing needs to be disabled if at least
+	 * one MAC does not use DSA.
+	 */
+	val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
+	val &= ~MTK_CDMP_STAG_EN;
+	mtk_w32(eth, val, MTK_CDMP_IG_CTRL);
+
  	err = phylink_of_phy_connect(mac->phylink, mac->of_node, 0);
  	if (err) {
  		netdev_err(dev, "%s: could not attach PHY: %d\n", __func__,

---

ChatGPT Remarks

Since I'm very slowly learning C, I had ChatGPT help with a compilation 
warning. And answer a question that neither DuckDuckGo or Google could 
answer.

Me:

> What is CDMP Ingress Control

ChatGPT:

> CDMP (Control Data Media Processor) Ingress Control is a feature of MediaTek Ethernet controllers that allows for the manipulation of the incoming data traffic before it is processed by the CPU.
> 
> It includes a set of rules and filters that can be applied to the incoming data traffic to selectively forward, drop, or redirect it to different queues. The CDMP Ingress Control feature is used to improve the performance and security of the Ethernet controller by allowing for the efficient handling of large amounts of data traffic.
> 
> For example, it can be used to prioritize certain types of traffic, such as voice or video, over others, or to drop unwanted traffic, such as spam or malicious packets. The CDMP Ingress Control feature also includes a set of statistics counters that allow for monitoring of the traffic and performance of the Ethernet controller.

Me:

> Could you make this warning go away by fixing the code below?
> 
> drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function ‘mtk_open’:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:3266:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
>  3266 |  u32 val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
>       |  ^~~
> 
> The code:
> 	u32 val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
> 	val &= ~MTK_CDMP_STAG_EN;
> 	mtk_w32(eth, val, MTK_CDMP_IG_CTRL);

ChatGPT:

> To fix the warning, the declaration of the variable "val" should be moved before any statements or expressions.
> 
> Here's how the code should look:
> 
> u32 val;
> val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
> val &= ~MTK_CDMP_STAG_EN;
> mtk_w32(eth, val, MTK_CDMP_IG_CTRL);
> 
> By moving the declaration of the variable before any statements or expressions, the C90 standard is no longer violated.
> 
> It's worth noting that it's often a good practice to initialize variables at the point of declaration, this way you can make sure the variable is always initialized before it's used.

Me:

> It didn't work, now I get this error:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function ‘mtk_open’:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:3266:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
>  3266 |  u32 val;
>       |  ^~~

ChatGPT:

> It looks like the error message you're seeing is related to the location of the variable declaration within the function. It appears that the variable "val" is being declared within a block of code that has statements or expressions before it, which is what is causing the "ISO C90 forbids mixed declarations and code" warning.
> 
> One way to fix this issue would be to move the variable declaration to the beginning of the function, before any statements or expressions.
> 
> You can also move the variable declaration to the top of the file, as a global variable.
> 
> Another way would be to make sure that the variable is declared before any statements or expressions in the block of code.
> 
> It's also possible that you're missing some header files or the variable definition is not correct. I would recommend checking that the variable definition is correct and that the correct header files are included in the code.
> 
> Please also note that you can also try to change your compile flag to a later standard (C99, C11) if they are available and supported by your compiler, this way you can avoid this warning.

This is ridiculous. I wonder if it could read the Linux kernel 
repository and fix/optimise code, dt-bindings, etc.
This thing could fix DT warnings accordingly with documentation much 
much much faster than a human can.

> 
> ---
> 
> ## MT7530 sends malformed packets to/from CPU at port 5 when port 6 is 
> not defined on devicetree
> 
> In this case, I can see eth1 receiving traffic as the receive counter on 
> ifconfig goes up with the ARP packets sent to the mt7621 CPU.
> 
> I see the mt7621 CPU not responding to the ARP packets (no malformed 
> packets or anything), which likely means ARP packets received on the 
> mt7621 CPU side are also malformed.
> 
> I think this confirms that the above issue is related to the MT7530 DSA 
> driver as I can see eth1 receiving traffic in this case.
> 
> Packet capture of the malformed packets are in the attachments.

This issue is still there for MT7621A but not MT7623NI. But now that the 
issue above is fixed (and I figured out how to boot vanilla Linux kernel 
with buildroot filesystem so I can include tcpdump with the image), I 
can see the malformed frames on the DSA master interface too.

> 
> ---
> 
> ## MT7621 Ethernet gmac1 won’t work when gmac0 is not defined on devicetree
> 
> eth0 interface is initalised even though it’s not defined on the 
> devicetree, eth1 interface is not created at all.
> 
> This is likely not related to the MT7530 DSA driver.

This is not an issue. gmac1 is named eth0 since gmac0 is not enabled. 
Opening network interfaces from MACs are named in arithmetic order.

Arınç

Re: gmac1 issues with mtk_eth_soc & port 5 issues with MT7530 DSA driver

[Arınç ÜNAL]

On 23.01.2023 19:19, Arınç ÜNAL wrote:
> After testing stuff out, I've got things to share on these issues.
> 
> All of this is tested on the current net-next/main on GB-PC2 and Unielec 
> U7621-06.
> 
> On 13.09.2022 15:54, Arınç ÜNAL wrote:
>> I'd like to post a few more issues I stumbled upon on mtk_eth_soc and 
>> MT7530 DSA drivers. All of this is tested on vanilla 6.0-rc5 on GB-PC2.
>>
>> ## MT7621 Ethernet gmac1 won’t work when gmac1 is used as DSA master 
>> for MT7530 switch
>>
>> There’s recently been changes on the MT7530 DSA driver by Frank to 
>> support using port 5 as a CPU port.
>>
>> The MT7530 switch’s port 5 is wired to the MT7621 SoC’s gmac1.
>>
>> Master eth1 and slave interfaces initialise fine. Packets are sent out 
>> from eth1 fine but won't be received on eth1.
>>
>> This issue existed before Lorenzo’s changes on 6.0-rc1.
>>
>> I’m not sure if this is an issue with mtk_eth_soc or the MT7530 DSA 
>> driver.
> 
> Traffic from CPU goes out through DSA slave fine. Traffic from DSA slave 
> to CPU reaches, RX bytes go up on eth1, but nothing on tcpdump.
> 
> Recently, I tried this on a Bananapi BPI-R2 (MT7623NI SoC). Everything 
> works fine after setting up eth0, `ip l set up eth0`. It still works 
> after setting down eth0. This makes me believe that, on mtk_eth_soc.c, 
> there is code for opening the first MAC, which is actually needed to 
> make communication work on all MACs. It should be moved to a more 
> generic location where the code will run even when the first MAC is not 
> being used.
> 
> After fiddling with the MediaTek ethernet driver, I found out that gmac1 
> works only when hardware special tag parsing is disabled. This is the 
> case for the MT7621A and MT7623NI SoCs.
> 
> With Felix's commit 2d7605a729062bb554f03c5983d8cfb8c0b42e9c ("net: 
> ethernet: mtk_eth_soc: enable hardware DSA untagging"), hardware special 
> tag parsing is disabled only when at least one MAC does not use DSA.
> 
> If someone could give me code to test where this function is disabled 
> for these two SoCs, I'd appreciate it.
> 
> Currently this works:
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 801deac58bf7..3c462179dcf6 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -3241,6 +3241,7 @@ static int mtk_open(struct net_device *dev)
>   {
>       struct mtk_mac *mac = netdev_priv(dev);
>       struct mtk_eth *eth = mac->hw;
> +    u32 val;
>       int i, err;
> 
>       if (mtk_uses_dsa(dev) && !eth->prog) {
> @@ -3258,15 +3259,15 @@ static int mtk_open(struct net_device *dev)
>               md_dst->u.port_info.port_id = i;
>               eth->dsa_meta[i] = md_dst;
>           }
> -    } else {
> -        /* Hardware special tag parsing needs to be disabled if at least
> -         * one MAC does not use DSA.
> -         */
> -        u32 val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
> -        val &= ~MTK_CDMP_STAG_EN;
> -        mtk_w32(eth, val, MTK_CDMP_IG_CTRL);
>       }
> 
> +    /* Hardware special tag parsing needs to be disabled if at least
> +     * one MAC does not use DSA.
> +     */
> +    val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
> +    val &= ~MTK_CDMP_STAG_EN;
> +    mtk_w32(eth, val, MTK_CDMP_IG_CTRL);
> +
>       err = phylink_of_phy_connect(mac->phylink, mac->of_node, 0);
>       if (err) {
>           netdev_err(dev, "%s: could not attach PHY: %d\n", __func__,

I've done some more tests and I'm confident this is caused by Felix's 
commit which enables hardware DSA untagging.

According to my tests on MT7621AT and MT7623NI SoCs, hardware DSA 
untagging is not supported on the second GMAC.

So I've got to disable this feature when the second gmac of MT7621 or 
MT7623 SoCs is enabled.

The MTK_GMAC1_TRGMII capability is only on the MT7621 and MT7623 SoCs 
which I see this problem on. I'm new to coding so I took an educated 
guess from the use of MTK_NETSYS_V2 to disable this feature altogether 
for MT7986 SoC.

I believe this check does it perfectly well. I tested it on both SoCs 
along with some debug info on different DTs.
- Only gmac0 as dsa master
- gmac0 & gmac1 as dsa master
- Only gmac1 as dsa master
- gmac0 as dsa master & gmac1 as non-dsa

if ((mtk_uses_dsa(dev) && !eth->prog) && !(mac->id == 1 && 
MTK_HAS_CAPS(eth->soc->caps, MTK_GMAC1_TRGMII)))

Initially, I wanted to disable this feature on MT7621 and MT7623 SoCs 
altogether but there's no reason to do this with the check above.

As a last note, I would appreciate it if new features are only enabled 
on SoCs which were thoroughly tested.

Arınç