Enable Armada SOCs and MVPP2 NIC driver for disco/generic arm64

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1835054

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Can't really provide logs here... One thing I figured out in the meantime is that the source package seems to be building it for armhf:

debian.master/config/config.common.ubuntu:CONFIG_MVPP2=m
debian.master/config/annotations:CONFIG_MVPP2 policy<{'armhf': 'm'}>

so perhaps all is needed is adding a policy for arm64.

Hello,
can you give this ARM64 test kernel a try?
https://people.canonical.com/~phlin/kernel/lp-1835054-mvpp2/

ubuntu@starmie-kernel:~$ grep MVPP /boot/config-5.0.0-2*
/boot/config-5.0.0-21-generic:CONFIG_MVPP2=m
ubuntu@starmie-kernel:~$ sudo modprobe mvpp2
ubuntu@starmie-kernel:~$ lsmod | grep mvpp2
mvpp2 110592 0
phylink 36864 1 mvpp2

Good news:

The module is *definitely* built and loads fine. Thanks!

Bad news:

The driver has some issues... Full boot log attached, but first of all, spot the delay:

...
[ 2.849454] mvpp2 MRVL0110:00 eth0: Using random mac address ee:ad:f4:3c:ad:cf
...
[ 2.932894] mvpp2 MRVL0110:01 eth1: Using random mac address 16:0c:52:c7:5a:cb
...
[ 2.946932] mvpp2 MRVL0110:01 eth2: Using random mac address 7a:b8:9a:01:af:46
...
[ 2.962885] mvpp2 MRVL0110:01 enamrvl110i1: renamed from eth1
...
[ 3.229057] mvpp2 MRVL0110:01 rename4: renamed from eth2
...
[ 3.504865] mvpp2 MRVL0110:00 enamrvl110i0: renamed from eth0
...
[ 5.334377] Virtual CRAT table created for CPU
[ 5.334414] Parsing CRAT table with 1 nodes
[ 5.334450] Creating topology SYSFS entries
[ 5.334512] Topology: Add CPU node
[ 5.334545] Finished initializing topology
[ 63.937562] systemd-udevd[201]: eth2: Worker [221] processing SEQNUM=1947 is taking a long time
[ 93.650969] systemd-udevd[221]: eth2: Failed to rename network interface 4 from 'eth2' to 'enamrvl110i1': File exists
[ 93.892377] raid6: neonx8 gen() 3687 MB/s
[ 93.940370] raid6: neonx8 xor() 3241 MB/s
[ 93.988376] raid6: neonx4 gen() 3112 MB/s
[ 94.036370] raid6: neonx4 xor() 2696 MB/s
[ 94.084377] raid6: neonx2 gen() 2644 MB/s
...

Then, the "rename4" interface gets IP over DHCP and things seems ok, until I start generating more traffic (like pulling a tarball from kernel.org)... Then the interface "hangs", ie. no more data gets in nor out, but without any messages in the kernel log.

For better or worse, these symptoms more or less match what I observed using Debian Buster installer over the weekend, so I suspect it's an issue with "my" firmware (I believe others made it work on Macchiatobin).

From the "missing driver" perspective, the problem has been fixed :-)

Update and good news:

I've been reminded that the firmware I have can boot the platform with either ACPI and Device Tree tables. I've been in ACPI mode and now, after flipping to DT, the platform boots fine and all 4 interfaces (one thing I haven't noticed that only one was completely missing previously) get detected and are functional. The wget kernel.org/big.tarball works fine now as well, so I think this proves that the CONFIG_MVPP2=m was all that was needed.

Thanks!

Hello,

thanks for the feedback and the test.

I have submitted this patch for SRU:
https://lists.ubuntu.com/archives/kernel-team/2019-July/102028.html
We might need your help to test this once it got applied for the next cycle.

To note that it's unlikely to get installer image re-generated (except for those daily build images). I have targeted the Eoan kernel (19.10) as well, it should work out-of-box for Eoan in the future when it got released if nothing goes wrong.

V2 resubmitted. https://lists.ubuntu.com/archives/kernel-team/2019-July/102171.html

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-disco' to 'verification-done-disco'. If the problem still exists, change the tag 'verification-needed-disco' to 'verification-failed-disco'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug was fixed in the package linux - 5.2.0-10.11

---------------
linux (5.2.0-10.11) eoan; urgency=medium

  * eoan/linux: 5.2.0-10.11 -proposed tracker (LP: #1838113)

  * Packaging resync (LP: #1786013)
    - [Packaging] resync git-ubuntu-log

  * Eoan update: v5.2.4 upstream stable release (LP: #1838428)
    - bnx2x: Prevent load reordering in tx completion processing
    - caif-hsi: fix possible deadlock in cfhsi_exit_module()
    - hv_netvsc: Fix extra rcu_read_unlock in netvsc_recv_callback()
    - igmp: fix memory leak in igmpv3_del_delrec()
    - ipv4: don't set IPv6 only flags to IPv4 addresses
    - ipv6: rt6_check should return NULL if 'from' is NULL
    - ipv6: Unlink sibling route in case of failure
    - net: bcmgenet: use promisc for unsupported filters
    - net: dsa: mv88e6xxx: wait after reset deactivation
    - net: make skb_dst_force return true when dst is refcounted
    - net: neigh: fix multiple neigh timer scheduling
    - net: openvswitch: fix csum updates for MPLS actions
    - net: phy: sfp: hwmon: Fix scaling of RX power
    - net_sched: unset TCQ_F_CAN_BYPASS when adding filters
    - net: stmmac: Re-work the queue selection for TSO packets
    - net/tls: make sure offload also gets the keys wiped
    - nfc: fix potential illegal memory access
    - r8169: fix issue with confused RX unit after PHY power-down on RTL8411b
    - rxrpc: Fix send on a connected, but unbound socket
    - sctp: fix error handling on stream scheduler initialization
    - sctp: not bind the socket in sctp_connect
    - sky2: Disable MSI on ASUS P6T
    - tcp: be more careful in tcp_fragment()
    - tcp: fix tcp_set_congestion_control() use from bpf hook
    - tcp: Reset bytes_acked and bytes_received when disconnecting
    - vrf: make sure skb->data contains ip header to make routing
    - net/mlx5e: IPoIB, Add error path in mlx5_rdma_setup_rn
    - net: bridge: mcast: fix stale nsrcs pointer in igmp3/mld2 report handling
    - net: bridge: mcast: fix stale ipv6 hdr pointer when handling v6 query
    - net: bridge: don't cache ether dest pointer on input
    - net: bridge: stp: don't cache eth dest pointer before skb pull
    - macsec: fix use-after-free of skb during RX
    - macsec: fix checksumming after decryption
    - netrom: fix a memory leak in nr_rx_frame()
    - netrom: hold sock when setting skb->destructor
    - selftests: txring_overwrite: fix incorrect test of mmap() return value
    - net/tls: fix poll ignoring partially copied records
    - net/tls: reject offload of TLS 1.3
    - net/mlx5e: Fix port tunnel GRE entropy control
    - net/mlx5e: Rx, Fix checksum calculation for new hardware
    - net/mlx5e: Fix return value from timeout recover function
    - net/mlx5e: Fix error flow in tx reporter diagnose
    - bnxt_en: Fix VNIC accounting when enabling aRFS on 57500 chips.
    - mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed
    - net/mlx5: E-Switch, Fix default encap mode
    - mlxsw: spectrum: Do not process learned records with a dummy FID
    - dma-buf: balance refcount inbalance
    - dma-buf: Discard old fence_excl on retrying get_fences_rcu for realloc
    - Revert "gpio/spi: Fix spi-gpio...

Hi Paweł,

I saw you were able to confirm the test kernel from comment #3 worked. The kernel that's in the -proposed repository should also contain this fix. If possible, could I trouble you to enable the -proposed repository [1] and install the new kernel to confirm that the fix is working as expected and should be released to everyone else?

Thanks!

Connor

[1] Enabling the proposed repository on Ubuntu: https://wiki.ubuntu.com/Testing/EnableProposed

Ah, of course - I should have noticed comment #8 myself, sorry...

Just booted with:

$ uname -a
Linux macchiatobin 5.0.0-25-generic #26-Ubuntu SMP Thu Aug 1 12:05:25 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
$ dpkg -S /boot/vmlinuz-5.0.0-25-generic
linux-image-5.0.0-25-generic: /boot/vmlinuz-5.0.0-25-generic

and it all looks fine, thanks!

May I also inquire about the installer, please? Will the daily builds, particularly the server flavour (as it's the one that is being built for aarch64 these days):

http://cdimage.ubuntu.com/ubuntu-server/daily/current/

get updated with the newer kernel once it's released into updates? It would be very important for less-experienced user...

This bug was fixed in the package linux - 5.0.0-25.26

---------------
linux (5.0.0-25.26) disco; urgency=medium

  * CVE-2019-1125
    - x86/cpufeatures: Carve out CQM features retrieval
    - x86/cpufeatures: Combine word 11 and 12 into a new scattered features word
    - x86/speculation: Prepare entry code for Spectre v1 swapgs mitigations
    - x86/speculation: Enable Spectre v1 swapgs mitigations
    - x86/entry/64: Use JMP instead of JMPQ
    - x86/speculation/swapgs: Exclude ATOMs from speculation through SWAPGS

 -- Kleber Sacilotto de Souza <email address hidden> Thu, 01 Aug 2019 12:04:35 +0200