HiSilicon HNS ethernet broken in 4.15.0-45

Bug #1818294 reported by Jo Shields
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Undecided
Unassigned
Bionic
Fix Released
Critical
dann frazier
Cosmic
Fix Released
Critical
dann frazier
Disco
Fix Released
Undecided
Unassigned

Bug Description

[Impact]
The 1G NICs on the Huawei XR320 system do not detect link on initial boot, resulting in broken networking. This is a regression caused by:

  308c6cafde01 ("net: hns: All ports can not work when insmod hns ko after rmmod.")

While that fixed an issue with phys after reloading the driver, it caused an issue with some phys on initial load.

[Test Case]
dmesg | grep "hns-nic HISI00C2:02 enahisic2i2: link up"
(With enahisic2i2 properly wired up)

[Fix]
This was addressed by upstream commit c77804be53369 ("net: hns: Fix WARNING when hns modules installed"). While the commit message suggests this was for a separate issue that we are not seeing (a WARNING message), it also resolves this issue.

[Regression Risk]
Restricted to the hns driver, which is only used by certain HiSilicon SOCs.

CVE References

Revision history for this message
dann frazier (dannf) wrote :

Thanks for subscribing me. I'd like to get to the bottom of your specific issue and get that addressed vs. dumping a bunch more patches in and hoping it fixes it. To aide in that, can you provide additional information about the issue? There should be an auto-update to this bug soon that provides a list of data to collect.

Revision history for this message
dann frazier (dannf) wrote :

Meanwhile, can you confirm whether or not this impacts the 4.18-based HWE kernel in 18.04? See: https://wiki.ubuntu.com/Kernel/LTSEnablementStack

Revision history for this message
Jo Shields (directhex) wrote :

I will, as soon as possible - but the 5.0rc1 mainline build has totally failed to boot, and I'm stuck waiting on remote hands before I can get more investigation done.

Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

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 1818294

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.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Jo Shields (directhex) wrote :

I still don't have remote hands on my server (!), but I've been able to extract a little more info by cross-referencing another server & checking the kernel git logs:

* There are two ethernet drivers, `hns` for first-gen and `hns3` for third-gen. No I don't know what happened to second-gen
* The TaiShan XR320/XA320 server node uses the previous-gen `hns` driver, not `hns3`
* There are no changes to `hns3` between v5.0-rc1 and v5.0-rc8 - only changes to `hns`
* I don't know which device is in the D05 or D06 development boards, nor the TaiShan 2280 2U server - they're not listed on the Ubuntu hardware certification page. On the XR320/XA320 it shows up in lspci as a "Signal processing controller" for some reason, not an ethernet controller, which might be why
* PCI ID is 19e5:1710, but that's not actually covered by the hns_enet_drv modaliases, which seem to identify via acpi instead of PCI ID (/sys/bus/acpi/devices/HISI00C2\:0*) for alias acpi*:HISI00C2:* hns_enet_drv

Revision history for this message
Jo Shields (directhex) wrote :

directhex@breakfast:/tmp/linux$ git diff --pretty=oneline v5.0-rc1..v5.0-rc8 -- drivers/net/ethernet/hisilicon/hns/ | diffstat
 hns_ae_adapt.c | 6 ++----
 hns_dsaf_main.c | 5 +++++
 hns_enet.c | 22 ++++++++++++----------
 hns_ethtool.c | 16 +++++++++-------
 4 files changed, 28 insertions(+), 21 deletions(-)

Also, that is not a lot of actual changes

Revision history for this message
dann frazier (dannf) wrote :

I don't think we yet know that one of the changes between 5.0-rc1 & 5.0-rc8 would fix this. It could be an issue with the backport, or a change in a different subsystem. But, as a test, I went ahead and backported the hns changes to a PPA:

https://launchpad.net/~dannf/+archive/ubuntu/xr320

If that build does fix the problem for you, then we can narrow down what the significant change(s) is. Of course, once you're able to test I suspect you'll also be able to collect the logs of the failing build, and that should give us more direct info.

dann frazier (dannf)
Changed in linux (Ubuntu Disco):
status: Incomplete → New
Changed in linux (Ubuntu Bionic):
status: New → Incomplete
Changed in linux (Ubuntu Cosmic):
status: New → Incomplete
Changed in linux (Ubuntu Disco):
status: New → Incomplete
Revision history for this message
Jo Shields (directhex) wrote :

My remote hands seem to be on vacation this week, so I'm bringing another machine out of service to use for testing. Should get the apport logs by the end of today.

Revision history for this message
Jo Shields (directhex) wrote :

I can't actually use `apport-collect` without an internet connection, of course, so can't use it when booted to a "bad" kernel

And `apport-bug linux` seems to only collect a fraction of the requisite logs.

I'll attach a "good" boot, at least, then try your PPA kernel.

Revision history for this message
Jo Shields (directhex) wrote :

(I'd love to know how to convince apport-bug to collect ALLLLLLLL these logs when offline, it seems to only grab the package list when I try it)

tags: added: apport-collected xenial
description: updated
Revision history for this message
Jo Shields (directhex) wrote :

OK, I have functioning networking with 4.15.0-45.48+xr320.1

Revision history for this message
dann frazier (dannf) wrote : Re: [Bug 1818294] Re: HiSilicon HNS ethernet broken in 4.15.0-45

On Wed, Mar 6, 2019 at 11:25 AM directhex <email address hidden> wrote:
>
> I can't actually use `apport-collect` without an internet connection, of
> course, so can't use it when booted to a "bad" kernel

Could you save 'dmesg' output of the bad kernel to a file and upload
that once you reboot to working networking?

Revision history for this message
Jo Shields (directhex) wrote :

Aha, cracked it - had to copy the source_linux.py hook to source_linux-hwe.py. Will attach apport from "bad" kernel

Revision history for this message
Jo Shields (directhex) wrote :

Nope, never mind, the docs on the Ubuntu wiki are wrong and it's now impossible to attach an apport report offline (apport-collect is now mandatory for existing bugs, and does not allow passing an apport file as a parameter)

I'll get & attach dmesg.

Revision history for this message
Jo Shields (directhex) wrote :

dmesg - the only difference from a "good" boot is the absence of "hns-nic HISI00C2:02 enahisic2i2: link up"

Revision history for this message
dann frazier (dannf) wrote :

On Wed, Mar 6, 2019 at 1:10 PM directhex <email address hidden> wrote:
>
> dmesg - the only difference from a "good" boot is the absence of "hns-
> nic HISI00C2:02 enahisic2i2: link up"

OK, thanks. Unfortunately, there's no smoking gun there, so I've
started a bisect and uploaded another test kernel to
https://launchpad.net/~dannf/+archive/ubuntu/xr320/+packages. Can you
give that a try once it finishes building?

  -dann

Revision history for this message
Jo Shields (directhex) wrote :

Looks like it's 4 hours per build, so I'll give it a shot in the morning.

Thanks for your help with the bisect - after v5.0-rc1 mainline failed to boot, I was worried about doing the bisect via 5.0 release candidate mainline builds

Revision history for this message
Jo Shields (directhex) wrote :

bisect 4.15.0-45.48+xr320.2 good

So the fix is in one of 263c6d75f9a544a3c2f8f6a26de4f4808d8f59cf, bb989501abcafa0de5f18b0ec0ec459b5b817908 or c77804be53369dd4c15bfc376cf9b45948194cab

Revision history for this message
dann frazier (dannf) wrote :

On Thu, Mar 7, 2019 at 7:45 AM directhex <email address hidden> wrote:
>
> bisect 4.15.0-45.48+xr320.2 good
>
> So the fix is in one of 263c6d75f9a544a3c2f8f6a26de4f4808d8f59cf,
> bb989501abcafa0de5f18b0ec0ec459b5b817908 or
> c77804be53369dd4c15bfc376cf9b45948194cab

Thanks. I'll just hand build the rest to save time. Here's the next one:
  http://people.canonical.com/~dannf/lp1818294/

  -dann

Revision history for this message
Jo Shields (directhex) wrote :

I am online with +xr320.3

So the fix is c77804be53369dd4c15bfc376cf9b45948194cab ?

The commit message doesn't make it _seem_ relevant, except for the reference to 2b3e88ea65287ba738a798622405b15344871085 which makes it seem like maybe prior to c77804be53369dd4c15bfc376cf9b45948194cab the state checking is screwed? Which explains why the dmesg difference is just whether it detected a link up or not.

Revision history for this message
Jo Shields (directhex) wrote :

- if (h->phy_if == PHY_INTERFACE_MODE_SGMII)
- phy_stop(phy_dev);

... if the interface supports sgmii, disable the device? Or am I reading that wrong

Revision history for this message
dann frazier (dannf) wrote :

On Thu, Mar 7, 2019 at 1:20 PM directhex <email address hidden> wrote:
>
> I am online with +xr320.3
>
> So the fix is c77804be53369dd4c15bfc376cf9b45948194cab ?

Apparently.

> The commit message doesn't make it _seem_ relevant, except for the
> reference to 2b3e88ea65287ba738a798622405b15344871085 which makes it
> seem like maybe prior to c77804be53369dd4c15bfc376cf9b45948194cab the
> state checking is screwed? Which explains why the dmesg difference is
> just whether it detected a link up or not.

Yeah, the commit message describes a different problem than the one
you are seeing, but I suspect you were also broken by 308c6cafde01,
because that added the phy_stop() call.

On Thu, Mar 7, 2019 at 1:30 PM directhex <email address hidden> wrote:
>
> - if (h->phy_if == PHY_INTERFACE_MODE_SGMII)
> - phy_stop(phy_dev);
>
> ... if the interface supports sgmii, disable the device? Or am I reading
> that wrong

It stops the underlying phy, but it should be started again when the
interface is brought up (hns_nic_net_up()). I don't know why it isn't
- perhaps another side-effect of calling phy_stop() before
phy_start(). Thanks for testing - I'll get this fix submitted.

dann frazier (dannf)
Changed in linux (Ubuntu Disco):
status: Incomplete → Fix Released
Changed in linux (Ubuntu Cosmic):
assignee: nobody → dann frazier (dannf)
Changed in linux (Ubuntu Bionic):
assignee: nobody → dann frazier (dannf)
Changed in linux (Ubuntu Cosmic):
status: Incomplete → In Progress
Changed in linux (Ubuntu Bionic):
status: Incomplete → In Progress
Revision history for this message
dann frazier (dannf) wrote :

@directhex: Would you mind also testing a build of the HWE kernel?

http://people.canonical.com/~dannf/lp1818294/hwe/

Revision history for this message
Jo Shields (directhex) wrote :

@dannf this 4.18.0 HWE build works for me.

builder@xam-taishan-4:~$ uname -a
Linux xam-taishan-4 4.18.0-16-generic #17 SMP Thu Mar 7 21:31:17 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
builder@xam-taishan-4:~$ ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=1.50 ms

Revision history for this message
dann frazier (dannf) wrote :

On Fri, Mar 8, 2019 at 10:05 AM directhex <email address hidden> wrote:
>
> @dannf this 4.18.0 HWE build works for me.
>
> builder@xam-taishan-4:~$ uname -a
> Linux xam-taishan-4 4.18.0-16-generic #17 SMP Thu Mar 7 21:31:17 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
> builder@xam-taishan-4:~$ ping -c 1 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=1.50 ms

Thanks!

dann frazier (dannf)
Changed in linux (Ubuntu Cosmic):
importance: Undecided → Critical
Changed in linux (Ubuntu Bionic):
importance: Undecided → Critical
dann frazier (dannf)
description: updated
Revision history for this message
Jo Shields (directhex) wrote :

This'll filter through to the HWE kernel in Xenial without needing to be individually tracked in this bug (or a new one), right?

Revision history for this message
dann frazier (dannf) wrote :

On Fri, Mar 8, 2019 at 2:00 PM Jo Shields <email address hidden> wrote:
>
> This'll filter through to the HWE kernel in Xenial without needing to be
> individually tracked in this bug (or a new one), right?

That is correct.

Changed in linux (Ubuntu Bionic):
status: In Progress → Fix Committed
Changed in linux (Ubuntu Cosmic):
status: In Progress → Fix Committed
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote :

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

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!

tags: added: verification-needed-cosmic
tags: added: verification-needed-bionic
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote :

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

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!

Revision history for this message
dann frazier (dannf) wrote :
Download full text (3.3 KiB)

@directhex: Are you able to test this on your XR320? I've regression tested on a HiSilicon D05 which uses the same driver (it worked before, still works now).

ubuntu@d05-5:~$ cat /proc/version
Linux version 4.15.0-47-generic (buildd@bos02-arm64-022) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #50-Ubuntu SMP Wed Mar 13 10:42:02 UTC 2019
ubuntu@d05-5:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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: enahisic2i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether a0:8c:f8:62:5b:58 brd ff:ff:ff:ff:ff:ff
    inet 10.228.68.94/24 brd 10.228.68.255 scope global enahisic2i0
       valid_lft forever preferred_lft forever
    inet6 fe80::a28c:f8ff:fe62:5b58/64 scope link
       valid_lft forever preferred_lft forever
3: enahisic2i1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a0:8c:f8:62:5b:59 brd ff:ff:ff:ff:ff:ff
4: enahisic2i2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a0:8c:f8:62:5b:5a brd ff:ff:ff:ff:ff:ff
5: enahisic2i3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a0:8c:f8:62:5b:5b brd ff:ff:ff:ff:ff:ff
6: enP10p17s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether ec:0d:9a:2f:d0:12 brd ff:ff:ff:ff:ff:ff
7: enP10p17s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether ec:0d:9a:2f:d0:13 brd ff:ff:ff:ff:ff:ff

ubuntu@d05-5:~$ cat /proc/version
Linux version 4.18.0-17-generic (buildd@bos02-arm64-075) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-16ubuntu3)) #18~18.04.1-Ubuntu SMP Fri Mar 15 15:27:57 UTC 2019
ubuntu@d05-5:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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: enahisic2i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether a0:8c:f8:62:5b:58 brd ff:ff:ff:ff:ff:ff
    inet 10.228.68.94/24 brd 10.228.68.255 scope global enahisic2i0
       valid_lft forever preferred_lft forever
    inet6 fe80::a28c:f8ff:fe62:5b58/64 scope link
       valid_lft forever preferred_lft forever
3: enahisic2i1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a0:8c:f8:62:5b:59 brd ff:ff:ff:ff:ff:ff
4: enahisic2i2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a0:8c:f8:62:5b:5a brd ff:ff:ff:ff:ff:ff
5: enahisic2i3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a0:8c:f8:62:5b:5b brd ff:ff:ff:ff:ff:ff
6: enP10p17s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DO...

Read more...

tags: added: verification-done-bionic verification-done-cosmic
removed: verification-needed-bionic verification-needed-cosmic
Revision history for this message
Jo Shields (directhex) wrote :

I've scheduled downtime on a host, it'll take an hour or two before I can reboot into a test kernel

Revision history for this message
Jo Shields (directhex) wrote :

This appears to not be included in 4.15.0-47-generic? I'm offline with the kernel, and can't see anything useful in changelog.Debian.gz

Revision history for this message
Jo Shields (directhex) wrote :

I'm an idiot and should have been trying the version from -proposed, of course. Working on it

Revision history for this message
Jo Shields (directhex) wrote :

OK, yes, confirmed I have ethernet with 4.15.0-48.51

Revision history for this message
dann frazier (dannf) wrote :

On Tue, Apr 16, 2019 at 1:50 PM Jo Shields <email address hidden> wrote:
>
> OK, yes, confirmed I have ethernet with 4.15.0-48.51

Awesome, thanks!

Revision history for this message
dann frazier (dannf) wrote :

On Tue, Apr 16, 2019 at 1:26 PM Jo Shields <email address hidden> wrote:
>
> I'm an idiot and should have been trying the version from -proposed, of
> course. Working on it

Whups, yeah - so was I :) I thought for sure I had enabled -proposed
on my D05....
Anyway, I was also an idiot and didn't realize I could just check our
weekly scheduled tests and see that the (correct) -proposed kernels
had both booted fine on D05, so I didn't need to do that test
manually.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (6.9 KiB)

This bug was fixed in the package linux - 4.18.0-18.19

---------------
linux (4.18.0-18.19) cosmic; urgency=medium

  * linux: 4.18.0-18.19 -proposed tracker (LP: #1822796)

  * Packaging resync (LP: #1786013)
    - [Packaging] update helper scripts
    - [Packaging] resync retpoline extraction

  * 3b080b2564287be91605bfd1d5ee985696e61d3c in ubuntu_btrfs_kernel_fixes
    triggers system hang on i386 (LP: #1812845)
    - btrfs: raid56: properly unmap parity page in finish_parity_scrub()

  * [SRU][B/C/OEM]IOMMU: add kernel dma protection (LP: #1820153)
    - ACPI / property: Allow multiple property compatible _DSD entries
    - PCI / ACPI: Identify untrusted PCI devices
    - iommu/vt-d: Force IOMMU on for platform opt in hint
    - iommu/vt-d: Do not enable ATS for untrusted devices
    - thunderbolt: Export IOMMU based DMA protection support to userspace
    - iommu/vt-d: Disable ATS support on untrusted devices

  * Huawei Hi1822 NIC has poor performance (LP: #1820187)
    - net-next: hinic: fix a problem in free_tx_poll()
    - hinic: remove ndo_poll_controller
    - net-next/hinic: add checksum offload and TSO support
    - hinic: Fix l4_type parameter in hinic_task_set_tunnel_l4
    - net-next/hinic:replace multiply and division operators
    - net-next/hinic:add rx checksum offload for HiNIC
    - net-next/hinic:fix a bug in set mac address
    - net-next/hinic: fix a bug in rx data flow
    - net: hinic: fix null pointer dereference on pointer hwdev
    - hinic: optmize rx refill buffer mechanism
    - net-next/hinic:add shutdown callback
    - net-next/hinic: replace disable_irq_nosync/enable_irq

  * [CONFIG] please enable highdpi font FONT_TER16x32 (LP: #1819881)
    - Fonts: New Terminus large console font
    - [Config]: enable highdpi Terminus 16x32 font support

  * [19.04 FEAT] qeth: Enhanced link speed - kernel part (LP: #1814892)
    - s390/qeth: report 25Gbit link speed

  * Avoid potential memory corruption on HiSilicon SoCs (LP: #1819546)
    - iommu/arm-smmu-v3: Avoid memory corruption from Hisilicon MSI payloads

  * CVE-2017-5715
    - x86/speculation: Apply IBPB more strictly to avoid cross-process data leak
    - x86/speculation: Propagate information about RSB filling mitigation to sysfs
    - x86/speculation: Add RETPOLINE_AMD support to the inline asm CALL_NOSPEC
      variant
    - x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support
    - x86/retpoline: Remove minimal retpoline support
    - x86/speculation: Update the TIF_SSBD comment
    - x86/speculation: Clean up spectre_v2_parse_cmdline()
    - x86/speculation: Remove unnecessary ret variable in cpu_show_common()
    - x86/speculation: Move STIPB/IBPB string conditionals out of
      cpu_show_common()
    - x86/speculation: Disable STIBP when enhanced IBRS is in use
    - x86/speculation: Rename SSBD update functions
    - x86/speculation: Reorganize speculation control MSRs update
    - sched/smt: Make sched_smt_present track topology
    - x86/Kconfig: Select SCHED_SMT if SMP enabled
    - sched/smt: Expose sched_smt_present static key
    - x86/speculation: Rework SMT state change
    - x86/l1tf: Show actual SMT state
    - x86/speculation: R...

Read more...

Changed in linux (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (14.6 KiB)

This bug was fixed in the package linux - 4.15.0-48.51

---------------
linux (4.15.0-48.51) bionic; urgency=medium

  * linux: 4.15.0-48.51 -proposed tracker (LP: #1822820)

  * Packaging resync (LP: #1786013)
    - [Packaging] update helper scripts
    - [Packaging] resync retpoline extraction

  * 3b080b2564287be91605bfd1d5ee985696e61d3c in ubuntu_btrfs_kernel_fixes
    triggers system hang on i386 (LP: #1812845)
    - btrfs: raid56: properly unmap parity page in finish_parity_scrub()

  * [P9][LTCTest][Opal][FW910] cpupower monitor shows multiple stop Idle_Stats
    (LP: #1719545)
    - cpupower : Fix header name to read idle state name

  * [amdgpu] screen corruption when using touchpad (LP: #1818617)
    - drm/amdgpu/gmc: steal the appropriate amount of vram for fw hand-over (v3)
    - drm/amdgpu: Free VGA stolen memory as soon as possible.

  * [SRU][B/C/OEM]IOMMU: add kernel dma protection (LP: #1820153)
    - ACPICA: AML parser: attempt to continue loading table after error
    - ACPI / property: Allow multiple property compatible _DSD entries
    - PCI / ACPI: Identify untrusted PCI devices
    - iommu/vt-d: Force IOMMU on for platform opt in hint
    - iommu/vt-d: Do not enable ATS for untrusted devices
    - thunderbolt: Export IOMMU based DMA protection support to userspace
    - iommu/vt-d: Disable ATS support on untrusted devices

  * Add basic support to NVLink2 passthrough (LP: #1819989)
    - powerpc/powernv/npu: Do not try invalidating 32bit table when 64bit table is
      enabled
    - powerpc/powernv: call OPAL_QUIESCE before OPAL_SIGNAL_SYSTEM_RESET
    - powerpc/powernv: Export opal_check_token symbol
    - powerpc/powernv: Make possible for user to force a full ipl cec reboot
    - powerpc/powernv/idoa: Remove unnecessary pcidev from pci_dn
    - powerpc/powernv: Move npu struct from pnv_phb to pci_controller
    - powerpc/powernv/npu: Move OPAL calls away from context manipulation
    - powerpc/pseries/iommu: Use memory@ nodes in max RAM address calculation
    - powerpc/pseries/npu: Enable platform support
    - powerpc/pseries: Remove IOMMU API support for non-LPAR systems
    - powerpc/powernv/npu: Check mmio_atsd array bounds when populating
    - powerpc/powernv/npu: Fault user page into the hypervisor's pagetable

  * Huawei Hi1822 NIC has poor performance (LP: #1820187)
    - net-next: hinic: fix a problem in free_tx_poll()
    - hinic: remove ndo_poll_controller
    - net-next/hinic: add checksum offload and TSO support
    - hinic: Fix l4_type parameter in hinic_task_set_tunnel_l4
    - net-next/hinic:replace multiply and division operators
    - net-next/hinic:add rx checksum offload for HiNIC
    - net-next/hinic:fix a bug in set mac address
    - net-next/hinic: fix a bug in rx data flow
    - net: hinic: fix null pointer dereference on pointer hwdev
    - hinic: optmize rx refill buffer mechanism
    - net-next/hinic:add shutdown callback
    - net-next/hinic: replace disable_irq_nosync/enable_irq

  * [CONFIG] please enable highdpi font FONT_TER16x32 (LP: #1819881)
    - Fonts: New Terminus large console font
    - [Config]: enable highdpi Terminus 16x32 font support

  * [19.04 FEAT] qeth: Enhanced link...

Changed in linux (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote : Update Released

The verification of the Stable Release Update for linux-azure has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.