net: bcmgenet: Workaround for Pi 4B network issue

[pelwell]

Some combinations of Pi 4Bs and Ethernet switches don't reliably get a
DCHP-assigned IP address, leaving the unit with a self=assigned 169.254
address.

Forcing renegotiation has been found to be an effective workaround, so
add an automatic renegotiation after the link comes up for the first
time.

See: #3108

Signed-off-by: Phil Elwell [email protected]

[pelwell]

With this patch applied, a "bad" Pi 4B connected to a "bad" switch successfully received a DHCP IP address and rebooted all night. The only known downside is that it also delays the point at which a "good" pairing gets an IP address by a few seconds. For users and applications wishing to minimise the boot time, I've added a module parameter (genet.force_reneg) to enable the feature. Adding genet.force_reneg=n to cmdline.txt disables the re-negotiation at boot.

[HiassofT]

Can you please make the workaround opt-in?

On managed switches negotiation can take quite some time - eg on my HP 1810-24G it takes about 5 seconds (some Ciscos are said to take even a lot longer) - and this means not only bootup time but also the chance of running into a timeout will increase.

For example in LibreELEC we use a default timeout of 10 seconds to wait before the network is up. With current 4.19 kernel this works fine and still had a lot of slack, even with my HP switch. But if the time to bring the network up is increased I (and users) will need to increase the default timeout (yes, it can be done from the GUI, but it's not nice).

Here's are some timing outputs from raspbian lite, Raspbian kernel 4.19.58 vs current 4.19.63 plus this PR

root@raspberrypi:~# cat systemd-analyze-4.19.58 
Startup finished in 1.630s (kernel) + 16.669s (userspace) = 18.300s 
graphical.target reached after 16.626s in userspace
root@raspberrypi:~# cat systemd-analyze-4.19.63 
Startup finished in 1.661s (kernel) + 21.946s (userspace) = 23.607s 
graphical.target reached after 21.903s in userspace
root@raspberrypi:~# grep eth0 dmesg-4.19.58 
[    6.842622] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    7.911671] bcmgenet fd580000.genet eth0: Link is Down
[   12.071813] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off
[   12.071859] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
root@raspberrypi:~# grep eth0 dmesg-4.19.63
[    6.902697] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    7.911865] bcmgenet fd580000.genet eth0: Link is Down
[   12.071907] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off
[   12.071946] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   12.072155] bcmgenet fd580000.genet eth0: Link is Down
[   17.271850] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off

[pelwell]

It's a question of getting the workaround deployed and tested as quickly as possible. As long as it is opt-in we're unlikely to get much in the way of feedback, but if opt-out causes an increase in problem reports then we can easily change the default.

Any thoughts, @popcornmix?

[HiassofT]

I understand that you'd like to fix the issue, but as the (hopefully temporary) workaround causes a regression it should not be on by default.

With opt-in the few affected users have a chance to use their RPis until the core issue has been found and fixed.

[pelwell]

Alright - the default is now disabled.

[radekjuthner]

Can the same problem occur again on the Raspberry Pi 5?

[6by9]

Can the same problem occur again on the Raspberry Pi 5?

No. The ethernet hardware on Pi5 is totally different (part of RP1 rather than the main SoC).