[Zesty] d-i: replace msm_emac with qcom_emac

[Manoj Iyer]

[Impact]
We landed a patch to support msm_emac module in initrd for amberwing platforms. But the upstream driver has since been renamed to qcom_emac. This module is needed in d-i's initrd so that these nics can be used to d-i install the system. The driver already exists in the zesty kernel under drivers/net/ethernet/qualcomm/emac/

Revert commit 14893d91c9c391f8a4c2668b96ffe60aa728ad23 and add qcom_emac to initrd, and change the module name to qcom_emac.

[Test Case]
D-I install zesty on amberwing platform and notice that DI does not recognize the onboard two port nic.

[Regression Potential]
At present this driver applies only to amberwing systems, any regression will be isolated to amberwing platforms. The over all risk of regression is low.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1677297

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.

[Manoj Iyer (manjo)]

qcom_emac driver that is in Zesty (4.10) kernel is able to bring up the interface but fails to get a DHCP address. This bug is currently blocked until upstream fixes the qcom_emac driver.

[Timur Tabi (timur-tabi)]

You need to back-port some patches from 4.11 if you want the driver to work. Look at our 4.10 rebase for details.

[Timur Tabi (timur-tabi)]

Also, you may need to load the at803x driver before bringing up the interface. I've noticed in some kernels, the link doesn't come up unless you load this driver first. I don't know why it's a requirement only on some kernels.

[Manoj Iyer (manjo)]

That is hard to SRU, we don't want to be adding unrelated modules to DI.

With at803x loaded
==================
ubuntu@ubuntu:~$ uname -a
Linux ubuntu 4.10.0-10-generic #13~ubunturc2+build.1-Ubuntu SMP Tue Feb 28
23:33:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$ lsmod | grep at803x
at803x
ubuntu@ubuntu:~$ lsmod | grep qcom
qcom_emac 40960 0
ubuntu@ubuntu:~$

eth0 Link encap:Ethernet HWaddr 8c:fd:f0:06:90:cd
           inet addr:10.228.66.102 Bcast:10.228.66.255 Mask:255.255.255.0

So clearly as a side effect of loading at803x qcom_emac is able to get an
IP address. But I am afraid this is not something we can justify as an
SRU.

On Wed, 29 Mar 2017, Timur Tabi wrote:

> Assuming that you did back-port enough, then you should try loading
> at803x.ko first. Technically, there is an erratum with that PHY that the
> driver resolves, although I've never seen it make a difference until today.
>
> On 03/29/2017 04:50 PM, Manoj Iyer wrote:
>> Timur,
>>
>> Based on https://bugs.launchpad.net/bandera/ubuntu-17.04/+bug/1657261 yes
>> this was backported from 4.11 to 4.10 and commited to zesty and to xenial.
>>
>> On Wed, 29 Mar 2017, Timur Tabi wrote:
>>
>>> Did you back-port driver from 4.11?
>>>
>>> On 03/29/2017 03:55 PM, Manoj Iyer wrote:
>>>>
>>>> I have a public bug to track the qcom_emac replacement for msm_emac. This
>>>> is currently blocked because qcom_emac that is in Zesty is unable to get
>>>> DHCP leases. Needs a fix from qti to the driver before we can sru the
>>>> change. It is my understanding that once we sru the required patches we
>>>> can request for a DI respin in zesty to pick up the updated kernel.
>>>>
>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297
>>>>
>>>> --
>>>> ============================
>>>> Manoj Iyer
>>>> Ubuntu/Canonical
>>>> ARM Servers - Cloud
>>>> ============================
>>>
>>>
>>
>> --
>> ============================
>> Manoj Iyer
>> Ubuntu/Canonical
>> ARM Servers - Cloud
>> ============================
>
>

--
============================
Manoj Iyer
Ubuntu/Canonical
ARM Servers - Cloud
============================

[Timur Tabi (timur-tabi)]

It's not unrelated. That is the actusl phy on the SDP.
________________________________________
From: Manoj Iyer [<email address hidden>]
Sent: Wednesday, March 29, 2017 10:11 PM
To: Timur Tabi
Cc: Manoj Iyer; Andrew Cloke; David Douglas; <email address hidden>
Subject: Re: Zesty use qcom_emac instead of msm_emac.

That is hard to SRU, we don't want to be adding unrelated modules to DI.

With at803x loaded
==================
ubuntu@ubuntu:~$ uname -a
Linux ubuntu 4.10.0-10-generic #13~ubunturc2+build.1-Ubuntu SMP Tue Feb 28
23:33:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$ lsmod | grep at803x
at803x
ubuntu@ubuntu:~$ lsmod | grep qcom
qcom_emac 40960 0
ubuntu@ubuntu:~$

eth0 Link encap:Ethernet HWaddr 8c:fd:f0:06:90:cd
           inet addr:10.228.66.102 Bcast:10.228.66.255 Mask:255.255.255.0

So clearly as a side effect of loading at803x qcom_emac is able to get an
IP address. But I am afraid this is not something we can justify as an
SRU.

On Wed, 29 Mar 2017, Timur Tabi wrote:

> Assuming that you did back-port enough, then you should try loading
> at803x.ko first. Technically, there is an erratum with that PHY that the
> driver resolves, although I've never seen it make a difference until today.
>
> On 03/29/2017 04:50 PM, Manoj Iyer wrote:
>> Timur,
>>
>> Based on https://bugs.launchpad.net/bandera/ubuntu-17.04/+bug/1657261 yes
>> this was backported from 4.11 to 4.10 and commited to zesty and to xenial.
>>
>> On Wed, 29 Mar 2017, Timur Tabi wrote:
>>
>>> Did you back-port driver from 4.11?
>>>
>>> On 03/29/2017 03:55 PM, Manoj Iyer wrote:
>>>>
>>>> I have a public bug to track the qcom_emac replacement for msm_emac. This
>>>> is currently blocked because qcom_emac that is in Zesty is unable to get
>>>> DHCP leases. Needs a fix from qti to the driver before we can sru the
>>>> change. It is my understanding that once we sru the required patches we
>>>> can request for a DI respin in zesty to pick up the updated kernel.
>>>>
>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297
>>>>
>>>> --
>>>> ============================
>>>> Manoj Iyer
>>>> Ubuntu/Canonical
>>>> ARM Servers - Cloud
>>>> ============================
>>>
>>>
>>
>> --
>> ============================
>> Manoj Iyer
>> Ubuntu/Canonical
>> ARM Servers - Cloud
>> ============================
>
>

--
============================
Manoj Iyer
Ubuntu/Canonical
ARM Servers - Cloud
============================

[Timur Tabi (timur-tabi)]

Sorry, I'm not sure what happened there. I meant to say that that is the
*actual* PHY on the SDP board. It's an Atheros 8031 PHY. I was hoping
that we could get away with the genphy driver that's built-in, but
apparently not.

Ubuntu should be building every PHY driver anyway. I don't know if
there's a way to automatically load only the PHY drivers that are on the
board. However, none of this is Centriq- or even ARM-specific. This is
standard procedure for most Ethernet drivers on any platform.

On 3/29/17, 10:22 PM, "<email address hidden> on behalf of Timur Tabi"
<<email address hidden> on behalf of <email address hidden>> wrote:

>It's not unrelated. That is the actusl phy on the SDP.
>________________________________________
>From: Manoj Iyer [<email address hidden>]
>Sent: Wednesday, March 29, 2017 10:11 PM
>To: Timur Tabi
>Cc: Manoj Iyer; Andrew Cloke; David Douglas; <email address hidden>
>Subject: Re: Zesty use qcom_emac instead of msm_emac.
>
>That is hard to SRU, we don't want to be adding unrelated modules to DI.
>
>With at803x loaded
>==================
>ubuntu@ubuntu:~$ uname -a
>Linux ubuntu 4.10.0-10-generic #13~ubunturc2+build.1-Ubuntu SMP Tue Feb 28
>23:33:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
>ubuntu@ubuntu:~$
>ubuntu@ubuntu:~$ lsmod | grep at803x
>at803x
>ubuntu@ubuntu:~$ lsmod | grep qcom
>qcom_emac 40960 0
>ubuntu@ubuntu:~$
>
>eth0 Link encap:Ethernet HWaddr 8c:fd:f0:06:90:cd
> inet addr:10.228.66.102 Bcast:10.228.66.255
>Mask:255.255.255.0
>
>So clearly as a side effect of loading at803x qcom_emac is able to get an
>IP address. But I am afraid this is not something we can justify as an
>SRU.
>
>
>On Wed, 29 Mar 2017, Timur Tabi wrote:
>
>> Assuming that you did back-port enough, then you should try loading
>> at803x.ko first. Technically, there is an erratum with that PHY that
>>the
>> driver resolves, although I've never seen it make a difference until
>>today.
>>
>> On 03/29/2017 04:50 PM, Manoj Iyer wrote:
>>> Timur,
>>>
>>> Based on https://bugs.launchpad.net/bandera/ubuntu-17.04/+bug/1657261
>>>yes
>>> this was backported from 4.11 to 4.10 and commited to zesty and to
>>>xenial.
>>>
>>> On Wed, 29 Mar 2017, Timur Tabi wrote:
>>>
>>>> Did you back-port driver from 4.11?
>>>>
>>>> On 03/29/2017 03:55 PM, Manoj Iyer wrote:
>>>>>
>>>>> I have a public bug to track the qcom_emac replacement for msm_emac.
>>>>>This
>>>>> is currently blocked because qcom_emac that is in Zesty is unable to
>>>>>get
>>>>> DHCP leases. Needs a fix from qti to the driver before we can sru the
>>>>> change. It is my understanding that once we sru the required patches
>>>>>we
>>>>> can request for a DI respin in zesty to pick up the updated kernel.
>>>>>
>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297
>>>>>
>>>>> --
>>>>> ============================
>>>>> Manoj Iyer
>>>>> Ubuntu/Canonical
>>>>> ARM Servers - Cloud
>>>>> ============================
>>>>
>>>>
>>>
>>> --
>>> ============================
>>> Manoj Iyer
>>> Ubuntu/Canonical
>>> ARM Servers - Cloud
>>> ============================
>>
>>
>
>--
>============================
>Manoj Iyer
>Ubuntu/Canonical
>ARM S...

[Manoj Iyer (manjo)]

> It's not unrelated. That is the actusl phy on the SDP.

and the same for REPs? our target cert platform?

> ________________________________________
> From: Manoj Iyer [<email address hidden>]
> Sent: Wednesday, March 29, 2017 10:11 PM
> To: Timur Tabi
> Cc: Manoj Iyer; Andrew Cloke; David Douglas; <email address hidden>
> Subject: Re: Zesty use qcom_emac instead of msm_emac.
>
> That is hard to SRU, we don't want to be adding unrelated modules to DI.
>
> With at803x loaded
> ==================
> ubuntu@ubuntu:~$ uname -a
> Linux ubuntu 4.10.0-10-generic #13~ubunturc2+build.1-Ubuntu SMP Tue Feb 28
> 23:33:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
> ubuntu@ubuntu:~$
> ubuntu@ubuntu:~$ lsmod | grep at803x
> at803x
> ubuntu@ubuntu:~$ lsmod | grep qcom
> qcom_emac 40960 0
> ubuntu@ubuntu:~$
>
> eth0 Link encap:Ethernet HWaddr 8c:fd:f0:06:90:cd
> inet addr:10.228.66.102 Bcast:10.228.66.255 Mask:255.255.255.0
>
> So clearly as a side effect of loading at803x qcom_emac is able to get an
> IP address. But I am afraid this is not something we can justify as an
> SRU.
>
>
> On Wed, 29 Mar 2017, Timur Tabi wrote:
>
>> Assuming that you did back-port enough, then you should try loading
>> at803x.ko first. Technically, there is an erratum with that PHY that the
>> driver resolves, although I've never seen it make a difference until today.
>>
>> On 03/29/2017 04:50 PM, Manoj Iyer wrote:
>>> Timur,
>>>
>>> Based on https://bugs.launchpad.net/bandera/ubuntu-17.04/+bug/1657261 yes
>>> this was backported from 4.11 to 4.10 and commited to zesty and to xenial.
>>>
>>> On Wed, 29 Mar 2017, Timur Tabi wrote:
>>>
>>>> Did you back-port driver from 4.11?
>>>>
>>>> On 03/29/2017 03:55 PM, Manoj Iyer wrote:
>>>>>
>>>>> I have a public bug to track the qcom_emac replacement for msm_emac. This
>>>>> is currently blocked because qcom_emac that is in Zesty is unable to get
>>>>> DHCP leases. Needs a fix from qti to the driver before we can sru the
>>>>> change. It is my understanding that once we sru the required patches we
>>>>> can request for a DI respin in zesty to pick up the updated kernel.
>>>>>
>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677297
>>>>>
>>>>> --
>>>>> ============================
>>>>> Manoj Iyer
>>>>> Ubuntu/Canonical
>>>>> ARM Servers - Cloud
>>>>> ============================
>>>>
>>>>
>>>
>>> --
>>> ============================
>>> Manoj Iyer
>>> Ubuntu/Canonical
>>> ARM Servers - Cloud
>>> ============================
>>
>>
>
> --
> ============================
> Manoj Iyer
> Ubuntu/Canonical
> ARM Servers - Cloud
> ============================
>
>

--
============================
Manoj Iyer
Ubuntu/Canonical
ARM Servers - Cloud
============================

[Timur Tabi (timur-tabi)]

Yes, the REP has the Atheros 8033, which uses the same driver.

[Manoj Iyer (manjo)]

With the PHY module and the qcom-emac driver enabled in D-I I am able to see the interface in the installer configure network screen.

  ┌─────────────────────┤ [!!] Configure the network ├──────────────────────┐
  │ │
  │ Your system has multiple network interfaces. Choose the one to use as │
  │ the primary network interface during the installation. If possible, │
  │ the first connected network interface found has been selected. │
  │ │
  │ Primary network interface: │
  │ │
  │ enP1s2: Mellanox Technologies MT27700 Family [ConnectX-4] │
  │ eth0: Ethernet │
  │ │
  │ <Go Back> │
  │ │
  └─────────────────────────────────────────────────────────────────────────┘

[Manoj Iyer (manjo)]

I built a DI where the initrd has both the PHY and the qcom_emac driver. The d-i installer now loads both at803x and qcom_emac, but dhclient fails to get a DHCP address. So, I am not sure what is going on with qcom_emac.. is there another module dependency I am missing ?

~ # lsmod
Module Size Used by
mlx5_ib 204800 0
ib_core 249856 1 mlx5_ib
uas 28672 0
usb_storage 77824 1 uas
at803x 16384 0
mlx5_core 479232 1 mlx5_ib
devlink 36864 1 mlx5_core
ptp 28672 1 mlx5_core
pps_core 24576 1 ptp
ahci_platform 16384 0
libahci_platform 20480 1 ahci_platform
libahci 45056 2 ahci_platform,libahci_platform
qcom_emac 49152 0
sdhci_acpi 16384 0
sdhci 65536 1 sdhci_acpi
xhci_plat_hcd 16384 0

~ # ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 8c:fd:f0:06:92:a5 brd ff:ff:ff:ff:ff:ff
3: enP1s2: <BROADCAST,MULTICAST> mtu 1500 qdisc mq qlen 1000
    link/ether 24:8a:07:97:30:16 brd ff:ff:ff:ff:ff:ff

~ # dhclient -v eth0
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/8c:fd:f0:06:92:a5
Sending on LPF/eth0/8c:fd:f0:06:92:a5
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0xc271fe77)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 (xid=0xc271fe77)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0xc271fe77)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 (xid=0xc271fe77)
............
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14 (xid=0xc271fe77)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0xc271fe77)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 (xid=0xc271fe77)
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
~ #

[Timur Tabi (timur-tabi)]

Can you try bringing up the interface manually, with ifconfig and a static IP address? The driver that's already in 4.10 should work as-is. I need to see the console output as the driver tries to bring the interface up, and dhclient hides all that.

[Manoj Iyer (manjo)]

~ # rmmod qcom_emac
~ # modprobe qcom_emac
~ # dmesg | tail -n 15

[ 211.382709] Atheros 8031 ethernet QCOM8070:00:04: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=QCOM8070:00:04, irq=-2)
[ 211.382789] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 4479.862691] Atheros 8031 ethernet QCOM8070:00:04: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=QCOM8070:00:04, irq=-2)
[ 4479.862752] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 4481.902187] 803x_aneg_done: SGMII link is not ok
[ 4644.846719] Atheros 8031 ethernet QCOM8070:00:04: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=QCOM8070:00:04, irq=-2)
[ 4644.846785] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 4646.905307] 803x_aneg_done: SGMII link is not ok
[50268.581165] libphy: emac-mdio: probed
[50268.582675] qcom-emac QCOM8070:00 eth0: hardware id 64.1, hardware version 1.3.0
[50491.411665] libphy: emac-mdio: probed
[50491.413174] qcom-emac QCOM8070:00 eth0: hardware id 64.1, hardware version 1.3.0
~ #

[Timur Tabi (timur-tabi)]

How about the ifconfig command to bring the interface up? This just shows that the drivers have loaded.

[Manoj Iyer (manjo)]

Timur,

I strongly suspect that the NMI watchdog softlockups caused by mlx5_core dma mapping is the root cause of why qcom_emac driver is unable to get a dhcp address. I blacklisted the mlx5_core driver and the soft lockups went away. Nate suggested that we might need some additional iommu related patches to address the soft lockup issue. I will build a kernel with those and see if I have any success. So, looks like qcom_emac driver is not at fault here.

[Manoj Iyer (manjo)]

The qcom_emac driver in the installer is able to get a DHCP lease once I blacklisted the mlx5_core module.

~ # lsmod
Module Size Used by
uas 28672 0
usb_storage 77824 1 uas
at803x 16384 1
devlink 36864 0
ptp 28672 0
pps_core 24576 1 ptp
ahci_platform 16384 0
libahci_platform 20480 1 ahci_platform
libahci 45056 2 ahci_platform,libahci_platform
qcom_emac 49152 0
sdhci_acpi 16384 0
sdhci 65536 1 sdhci_acpi
xhci_plat_hcd 16384 0
~ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 8c:fd:f0:06:92:a5 brd ff:ff:ff:ff:ff:ff
    inet 10.228.66.113/24 brd 10.228.66.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::8efd:f0ff:fe06:92a5/64 scope link
       valid_lft forever preferred_lft forever
~ # cat /proc/cmdline
BOOT_IMAGE=/ubuntu-installer/arm64/linux module_blacklist=mlx5_core --- quiet
~ #

[Michael Reed (mreed8855)]

I did a D-I install on the qdf 2400 server with zesty + the patchset, using the Mellanox adapter (Ethernet controller: Mellanox Technologies MT27700 Family [ConnectX-4]). The qcom_emac driver is installed but the port (eth0) does not get an IP address without running dhclient -v. An IP address is assigned but not seen with the ifconfig command. I am able to ssh into that system using the assigned IP address, that I can only see from the output of the dhclient command.

[Michael Reed (mreed8855)]

Also we tried the workaround in comment #16 and blacklisting the mlx5_core module during the install and eth0 was not available.

[ 16.198090] Atheros 8031 ethernet QCOM8070:00:04: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=QCOM8070:00:04, irq=-2)
[ 16.198153] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 18.258062] 803x_aneg_done: SGMII link is not ok

[Manoj Iyer (manjo)]

on my qdf2400 server. Looks like dhclient is able to get a lease and ifconfig displays the ip address.

ubuntu@ubuntu:~$ sudo dhclient -v eth0
[sudo] password for ubuntu:
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/8c:fd:f0:06:92:a5
Sending on LPF/eth0/8c:fd:f0:06:92:a5
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x1b76e36a)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 (xid=0x1b76e36a)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0x1b76e36a)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0x1b76e36a)
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 (xid=0x1b76e36a)
DHCPREQUEST of 10.228.66.113 on eth0 to 255.255.255.255 port 67 (xid=0x6ae3761b)
DHCPOFFER of 10.228.66.113 from 10.228.66.3
DHCPACK of 10.228.66.113 from 10.228.66.3
bound to 10.228.66.113 -- renewal in 268 seconds.

ubuntu@ubuntu:~$ ifconfig
enP1s2 Link encap:Ethernet HWaddr 24:8a:07:97:30:16
          inet addr:10.228.66.114 Bcast:10.228.66.255 Mask:255.255.255.0
          inet6 addr: fe80::268a:7ff:fe97:3016/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:5290 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1752 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3115155 (3.1 MB) TX bytes:368794 (368.7 KB)

eth0 Link encap:Ethernet HWaddr 8c:fd:f0:06:92:a5
          inet addr:10.228.66.113 Bcast:10.228.66.255 Mask:255.255.255.0
          inet6 addr: fe80::8efd:f0ff:fe06:92a5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:950 (950.0 B) TX bytes:2436 (2.4 KB)
          Interrupt:40

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:160 errors:0 dropped:0 overruns:0 frame:0
          TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11840 (11.8 KB) TX bytes:11840 (11.8 KB)

ubuntu@ubuntu:~$ uname -a
Linux ubuntu 4.10.0-19-generic #21ubuntuRC04+patchset.1-Ubuntu SMP Mon Apr 10 17:09:12 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@ubuntu:~$

[Manoj Iyer (manjo)]

Timur found that the at803x module (needed for an erratum) is the reason we are unable to get a dhcp lease on the emac interface. He is exploring his options on fixing the issue, ie have a an option to pass in a phy driver if the erratum is encountered. We found that on my SDP we did not need the at803x module, and that the qcom_emac was able to use the generic phy to come up and get dhcp leases.

[Manoj Iyer (manjo)]

qcom_emac works fine with the generic phy driver, either the at803x driver needs to be fixed or the underlying userspace utils like dhclient needs to retry bringing up the link when it is reported as down. This should not be a blocker for switching from msm_emac to qcom_emac for d-i.

[Thadeu Lima de Souza Cascardo (cascardo)]

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-zesty' to 'verification-done-zesty'. If the problem still exists, change the tag 'verification-needed-zesty' to 'verification-failed-zesty'.

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!

[Manoj Iyer (manjo)]

Downloaded the netboot installer from
http://ports.ubuntu.com/dists/zesty-proposed/main/installer-arm64/current/images/netboot/

But I dont see the qcom_emac driver
/lib/modules/4.10.0-19-generic/kernel/drivers/net/ethernet # ls
3com broadcom fealnx.ko natsemi sfc
8390 cavium hisilicon neterion sis
adaptec cisco hp nvidia smsc
amd dec intel packetengines sun
apm dlink marvell qlogic ti
atheros emulex mellanox realtek via
/lib/modules/4.10.0-19-generic/kernel/drivers/net/ethernet #

Was this patch dropped?

[Kleber Sacilotto de Souza (kleber-souza)]

The fix was included on Zesty kernel 4.10.0-22.24, the netboot installer is loading 4.10.0-19, which is probably the GA kernel. I'm trying to find some sort of daily netboot build so it can be tested with the latest kernel.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 4.10.0-22.24

---------------
linux (4.10.0-22.24) zesty; urgency=low

  * linux: 4.10.0-22.24 -proposed tracker (LP: #1691146)

  * Fix NVLINK2 TCE route (LP: #1690155)
    - powerpc/powernv: Fix TCE kill on NVLink2

  * CVE-2017-0605
    - tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

  * perf: qcom: Add L3 cache PMU driver (LP: #1689856)
    - [Config] CONFIG_QCOM_L3_PMU=y
    - perf: qcom: Add L3 cache PMU driver

  * No PMU support for ACPI-based arm64 systems (LP: #1689661)
    - drivers/perf: arm_pmu: rework per-cpu allocation
    - drivers/perf: arm_pmu: manage interrupts per-cpu
    - drivers/perf: arm_pmu: split irq request from enable
    - drivers/perf: arm_pmu: remove pointless PMU disabling
    - drivers/perf: arm_pmu: define armpmu_init_fn
    - drivers/perf: arm_pmu: fold init into alloc
    - drivers/perf: arm_pmu: factor out pmu registration
    - drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs()
    - drivers/perf: arm_pmu: handle no platform_device
    - drivers/perf: arm_pmu: rename irq request/free functions
    - drivers/perf: arm_pmu: split cpu-local irq request/free
    - drivers/perf: arm_pmu: move irq request/free into probe
    - drivers/perf: arm_pmu: split out platform device probe logic
    - arm64: add function to get a cpu's MADT GICC table
    - [Config] CONFIG_ARM_PMU_ACPI=y
    - drivers/perf: arm_pmu: add ACPI framework
    - arm64: pmuv3: handle !PMUv3 when probing
    - arm64: pmuv3: use arm_pmu ACPI framework

  * [SRU][Zesty]QDF2400 kernel oops on ipmitool fru write 0 fru.bin
    (LP: #1689886)
    - ipmi: Fix kernel panic at ipmi_ssif_thread()

  * tty: pl011: fix earlycon work-around for QDF2400 erratum 44 (LP: #1689818)
    - tty: pl011: fix earlycon work-around for QDF2400 erratum 44
    - tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44

  * kernel-wedge fails in artful due to leftover squashfs-modules d-i files
    (LP: #1688259)
    - Remove squashfs-modules files from d-i
    - [Config] as squashfs-modules is builtin kernel-image must Provides: it

  * arm64/ACPI support for SBSA watchdog (LP: #1688114)
    - clocksource: arm_arch_timer: clean up printk usage
    - clocksource: arm_arch_timer: rename type macros
    - clocksource: arm_arch_timer: rename the PPI enum
    - clocksource: arm_arch_timer: move enums and defines to header file
    - clocksource: arm_arch_timer: add a new enum for spi type
    - clocksource: arm_arch_timer: rework PPI selection
    - clocksource: arm_arch_timer: split dt-only rate handling
    - clocksource: arm_arch_timer: refactor arch_timer_needs_probing
    - clocksource: arm_arch_timer: move arch_timer_needs_of_probing into DT init
      call
    - clocksource: arm_arch_timer: add structs to describe MMIO timer
    - clocksource: arm_arch_timer: split MMIO timer probing.
    - [Config] CONFIG_ACPI_GTDT=y
    - acpi/arm64: Add GTDT table parse driver
    - clocksource: arm_arch_timer: simplify ACPI support code.
    - acpi/arm64: Add memory-mapped timer support in GTDT driver
    - clocksource: arm_arch_timer: add GTDT support for memory-mapped timer
    - acpi/arm64: Add SBS...

[Kleber Sacilotto de Souza (kleber-souza)]

Hi @manjo,

It seems that we don't have daily netboot install images for arm64. Could you please try to create a DI with Zesty kernel 4.10.0-22.24 and check whether the module is being loaded properly?

Thank you.

[Manoj Iyer (manjo)]

kleber-souza,

Oh wow I did not notice that it was still loading the GA kernel and there is no netboot image for arm64 in daily. I will build a DI and test it and report back here.

[Manoj Iyer (manjo)]

I built DI and booted the netboot image on an SDP. DI works as expected with the patch.

 ┌─────────────────────┤ [!!] Configure the network ├──────────────────────┐
  │ │
  │ Your system has multiple network interfaces. Choose the one to use as │
  │ the primary network interface during the installation. If possible, │
  │ the first connected network interface found has been selected. │
  │ │
  │ Primary network interface: │
  │ │
  │ enP1s1: Mellanox Technologies MT27700 Family [ConnectX-4] │
  │ eth0: Ethernet │
  │ │
  │ <Go Back>

~ # lsmod
Module Size Used by
mlx5_ib 204800 0
ib_core 249856 1 mlx5_ib
uas 28672 0
usb_storage 77824 1 uas
mlx5_core 479232 1 mlx5_ib
devlink 36864 1 mlx5_core
ptp 28672 1 mlx5_core
pps_core 24576 1 ptp
ahci_platform 16384 0
libahci_platform 20480 1 ahci_platform
libahci 45056 2 ahci_platform,libahci_platform
qcom_emac 49152 0
sdhci_acpi 16384 0
sdhci 65536 1 sdhci_acpi
xhci_plat_hcd 16384 0
~ #

[Manoj Iyer (manjo)]

~ # uname -a
Linux (none) 4.10.0-22-generic #24~lp1677297+test.1-Ubuntu SMP Fri Jun 2 18:09:55 UTC 2017 aarch64 GNU/Linux
~ #

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 4.10.0-22.24

---------------
linux (4.10.0-22.24) zesty; urgency=low

  * linux: 4.10.0-22.24 -proposed tracker (LP: #1691146)

  * Fix NVLINK2 TCE route (LP: #1690155)
    - powerpc/powernv: Fix TCE kill on NVLink2

  * CVE-2017-0605
    - tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

  * perf: qcom: Add L3 cache PMU driver (LP: #1689856)
    - [Config] CONFIG_QCOM_L3_PMU=y
    - perf: qcom: Add L3 cache PMU driver

  * No PMU support for ACPI-based arm64 systems (LP: #1689661)
    - drivers/perf: arm_pmu: rework per-cpu allocation
    - drivers/perf: arm_pmu: manage interrupts per-cpu
    - drivers/perf: arm_pmu: split irq request from enable
    - drivers/perf: arm_pmu: remove pointless PMU disabling
    - drivers/perf: arm_pmu: define armpmu_init_fn
    - drivers/perf: arm_pmu: fold init into alloc
    - drivers/perf: arm_pmu: factor out pmu registration
    - drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs()
    - drivers/perf: arm_pmu: handle no platform_device
    - drivers/perf: arm_pmu: rename irq request/free functions
    - drivers/perf: arm_pmu: split cpu-local irq request/free
    - drivers/perf: arm_pmu: move irq request/free into probe
    - drivers/perf: arm_pmu: split out platform device probe logic
    - arm64: add function to get a cpu's MADT GICC table
    - [Config] CONFIG_ARM_PMU_ACPI=y
    - drivers/perf: arm_pmu: add ACPI framework
    - arm64: pmuv3: handle !PMUv3 when probing
    - arm64: pmuv3: use arm_pmu ACPI framework

  * [SRU][Zesty]QDF2400 kernel oops on ipmitool fru write 0 fru.bin
    (LP: #1689886)
    - ipmi: Fix kernel panic at ipmi_ssif_thread()

  * tty: pl011: fix earlycon work-around for QDF2400 erratum 44 (LP: #1689818)
    - tty: pl011: fix earlycon work-around for QDF2400 erratum 44
    - tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44

  * kernel-wedge fails in artful due to leftover squashfs-modules d-i files
    (LP: #1688259)
    - Remove squashfs-modules files from d-i
    - [Config] as squashfs-modules is builtin kernel-image must Provides: it

  * arm64/ACPI support for SBSA watchdog (LP: #1688114)
    - clocksource: arm_arch_timer: clean up printk usage
    - clocksource: arm_arch_timer: rename type macros
    - clocksource: arm_arch_timer: rename the PPI enum
    - clocksource: arm_arch_timer: move enums and defines to header file
    - clocksource: arm_arch_timer: add a new enum for spi type
    - clocksource: arm_arch_timer: rework PPI selection
    - clocksource: arm_arch_timer: split dt-only rate handling
    - clocksource: arm_arch_timer: refactor arch_timer_needs_probing
    - clocksource: arm_arch_timer: move arch_timer_needs_of_probing into DT init
      call
    - clocksource: arm_arch_timer: add structs to describe MMIO timer
    - clocksource: arm_arch_timer: split MMIO timer probing.
    - [Config] CONFIG_ACPI_GTDT=y
    - acpi/arm64: Add GTDT table parse driver
    - clocksource: arm_arch_timer: simplify ACPI support code.
    - acpi/arm64: Add memory-mapped timer support in GTDT driver
    - clocksource: arm_arch_timer: add GTDT support for memory-mapped timer
    - acpi/arm64: Add SBS...