[UBUNTU 20.04] s390x/pci: enumerate pci functions per physical adapter

Bug #1874056 reported by bugproxy
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Fix Released
Medium
Skipper Bug Screeners
linux (Ubuntu)
Fix Released
Undecided
Canonical Kernel Team
Focal
Fix Released
Medium
Unassigned
Groovy
Fix Released
Undecided
Canonical Kernel Team

Bug Description

SRU Justification:
==================

[Impact]

* Mellanox CX5 port multi-pathing is broken on s390x due to non-standard topology of PCI IDs (phys. and virtual)

* The Mellanox Connect-X 5 PCI driver (mlx5) implements multi-path that can be used to combine multiple networking ports to improve performance and reliability.

* For that purpose, the mlx5 driver combines PCI functions based on topology information (the function number) as determined by their PCI ID.

* Currently the Linux on Z PCI bus does not reflect PCI topology information in the PCI ID. As a result, the mlx5 multi-path function is broken and cannot be activated.

[Fix]

* Backport 1: https://launchpadlibrarian.net/479699471/0001-s390-pci-Improve-handling-of-unset-UID.patch

* Backport 2: https://launchpadlibrarian.net/479699482/0002-s390-pci-embedding-hotplug_slot-in-zdev.patch

* Backport 3: https://launchpadlibrarian.net/479699492/0003-s390-pci-Expose-new-port-attribute-for-PCIe-function.patch

* Backport 4: https://launchpadlibrarian.net/479699497/0004-s390-pci-adaptation-of-iommu-to-multifunction.patch

* Backport 5: https://launchpadlibrarian.net/479700706/0005-s390-pci-define-kernel-parameters-for-PCI-multifunct.patch

* Backport 6: https://launchpadlibrarian.net/479700712/0006-s390-pci-define-RID-and-RID-available.patch

* Backport 7: https://launchpadlibrarian.net/479700739/0007-s390-pci-create-zPCI-bus.patch

* Backport 8: https://launchpadlibrarian.net/479700769/0008-s390-pci-adapt-events-for-zbus.patch

* Backport 9: https://launchpadlibrarian.net/479700786/0009-s390-pci-Handling-multifunctions.patch

* Backport 10: https://launchpadlibrarian.net/479700794/0010-s390-pci-Do-not-disable-PF-when-VFs-exist.patch

* Backport 11: https://launchpadlibrarian.net/479700798/0011-s390-pci-Documentation-for-zPCI.patch

* Backport 12: https://launchpadlibrarian.net/479700799/0012-s390-pci-removes-wrong-PCI-multifunction-assignment.patch

[Test Case]

* Prepare an IBM z13 or LinuxONE III (or newer) system with two or more RoCE Express PCI 2(.1) adapters.

* Assign the adapters (and it's virtual functions) to an LPAR.

* Verify whether the physical and virtual functions are grouped in arbitrary order or in consecutive order - physical first (for example with lspci -t ...)

[Regression Potential]

* The regression potential can be considered as moderate, since:

* It is purely s390x specific code (arch/s390/* drivers/iommu/s390-iommu.c and drivers/pci/hotplug/s390_pci_hpc.c - and some doc adjustments, too).

* It largely affects zPCI, the s390x specific PCI code layer.

* PCI cards available for s390x are optional cards (RoCE and zEDC) and not very wide-spread.

* The situation described above affects the RoCE adapters only (Mellanox based).

* The patches are also upstream accepted and available via linux-next, but to apply them to focal kernel 5.4 the above backports are needed.

* However, the code is modified by several patches (12), hence there is a chance to break zPCI with them.

* For upfront testing a PPA got created with a focal (master-next) kernel that incl. all the above patches.

__________

Today, the enumeration of PCI functions on s390x does not reflect which functions belongs to which physical adapter.

Layout of a PCI function address on Linux:
0000:00:00.0
<root complex>:<bus>:<device>.<function>

On s390x, each function is presented as individual root complex today, e.g.:

PCHID 0100 VF1 0000:00:00.0
PCHID 0100 VF23 0001:00:00.0
PCHID 0200 VF1 0002:00:00.0
OCHID 0100 VF17 0003:00:00.0

On other platforms, the addresses correctly reflect the actual HW configuration. Some device drivers (mlx5 for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for <root complex>:<bus>:<device>. We need to use the same enumeration scheme to achieve this functionality on s390x.

In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1, and all virtual functions need to use the same <root complex>:<bus> numbers with function/device numbers counting up.

Required result (example with 4 VFs per PF):

PCHID 0100 PF 0 0000:00:00.0
PCHID 0100 PF 1 0000:00:00.1
PCHID 0100 PF 0 VF 0 0000:00:00.2
PCHID 0100 PF 0 VF 1 0000:00:00.3
PCHID 0100 PF 0 VF 2 0000:00:00.4
PCHID 0100 PF 0 VF 3 0000:00:00.5
PCHID 0100 PF 1 VF 0 0000:00:00.6
PCHID 0100 PF 1 VF 1 0000:00:00.7
PCHID 0100 PF 1 VF 2 0000:00:00.8
PCHID 0100 PF 1 VF 3 0000:00:00.9

PCHID 0200 PF 0 0001:00:00.0

bugproxy (bugproxy)
tags: added: architecture-s39064 bugnameltc-184172 severity-high targetmilestone-inin2004
Changed in ubuntu:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
affects: ubuntu → linux (Ubuntu)
summary: - s390x/pci: enumerate pci functions per physical adapter
+ [UBUNTU 20.04] s390x/pci: enumerate pci functions per physical adapter
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2020-04-21 09:53 EDT-------
Today, the enumeration of PCI functions on s390x does not reflect which functions belongs to which physical adapter.

Layout of a PCI function address on Linux:
0000:00:00.0
<root complex>:<bus>:<device>.<function>

On s390x, each function is presented as individual root complex today, e.g.:

PCHID 0100 VF1 0000:00:00.0
PCHID 0100 VF23 0001:00:00.0
PCHID 0200 VF1 0002:00:00.0
OCHID 0100 VF17 0003:00:00.0

On other platforms, the addresses correctly reflect the actual HW configuration. Some device drivers (mlx5 for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for <root complex>:<bus>:<device>. We need to use the same enumeration scheme to achieve this functionality on s390x.

In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1, and all virtual functions need to use the same <root complex>:<bus> numbers with function/device numbers counting up.

Required result (example with 4 VFs per PF):

PCHID 0100 PF 0 0000:00:00.0
PCHID 0100 PF 1 0000:00:00.1
PCHID 0100 PF 0 VF 0 0000:00:00.2
PCHID 0100 PF 0 VF 1 0000:00:00.3
PCHID 0100 PF 0 VF 2 0000:00:00.4
PCHID 0100 PF 0 VF 3 0000:00:00.5
PCHID 0100 PF 1 VF 0 0000:00:00.6
PCHID 0100 PF 1 VF 1 0000:00:00.7
PCHID 0100 PF 1 VF 2 0000:00:00.8
PCHID 0100 PF 1 VF 3 0000:00:00.9

PCHID 0200 PF 0 0001:00:00.0

Frank Heimes (fheimes)
description: updated
Revision history for this message
Frank Heimes (fheimes) wrote :

The mentioned modification makes sense.
But was this change already brought upstream?
And if so you you please share the commit (or backport) that does apply cleanly to the focal master-next tree?

Changed in ubuntu-z-systems:
status: New → Incomplete
importance: Undecided → Medium
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-04-22 10:49 EDT-------
The code is not upstream yet, it's also likely too big for v5.7-rcX but we are hoping it will hit our public tree at

https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git

soon? and since this is very important for the cloud project we wanted to have the bug open to start discussions. When that happens we will provide a backport.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-05-05 03:15 EDT-------
The commits for this are now available in the features branch of the public s390 Kernel repository on kernel.org, there is no common code impact and behavior for existing systems is unaffected
https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-05-05 03:24 EDT-------
In particular the relevant commits are:

e6ab7490ffaed83d6581f512e66c7c8cc6f58c2d s390/pci: Expose new port attribute for PCIe functions
d08d6f5d75242ceb410efbdf650efecc40d68c2d s390/pci: adaptation of iommu to multifunction
6cf17f9a67c124aa4739b79709008d942635b975 s390/pci: define kernel parameters for PCI multifunction
c9a1752b84f1a8f73187c116ff0514b2ab24d878 s390/pci: define RID and RID available
05bc1be6db4b2683bbf5b9394a75d0fb3acfcede s390/pci: create zPCI bus
f606b3ef47c9f874af605323099663a10f691b24 s390/pci: adapt events for zbus
65e450a9f9adabf3de1305a4c616f1313df402a3 s390/pci: Adding bus resource
44510d6fa0c00aa90b80075caa6b313b25927475 s390/pci: Handling multifunctions
53dd462ac4dc3fc61ee90ad03d96202e17589156 s390/pci: Do not disable PF when VFs exist
de267a7c71ba6be7857da0185871759067513d9c s390/pci: Documentation for zPCI

Revision history for this message
Frank Heimes (fheimes) wrote :

According to the bug title this all should still land in 20.04?

Please notice that 20.04 got already released, hence the development is over and the window to add new features is largely closed.
Requesting changes to an already released Ubuntu version is now strictly regulated by the Stable Release Upgrade (SRU) process: https://wiki.ubuntu.com/StableReleaseUpdates
Especially: https://wiki.ubuntu.com/StableReleaseUpdates#When
shows that the SRU process is mainly for critical bugs, security issues and regressions.

Based on these SRU guidelines, the above patches now need to be strictly screened.
For larger patch sets there is usually the HWE kernel available to get things in - or (especially when reading about Cloud) a custom kernel.

Such larger modifications and updates should generally land when the target Ubuntu release is still in development.

Next step is to have a look at the code and where it currently is (upstream) ...

Revision history for this message
Frank Heimes (fheimes) wrote :

The commits landed in between in linux-next (not tagged yet, but that's fine).
So it's all brand new stuff ...
I think the chance it not very high that they are just cleanly cherry-pick-able - having the other PCI changes in mind, too.

I guess you are thinking about backporting them to focal master-next?
$ git clone https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal --branch master-next --single-branch focal-master-next

Revision history for this message
Frank Heimes (fheimes) wrote :

Compiles now on 18.04 with 2nd backport instead of the cherry-pick.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-05-11 13:24 EDT-------
(In reply to comment #15)
> Compiles now on 18.04 with 2nd backport instead of the cherry-pick.

I think this was meant for "[UBUNTU 18.04] zpcictl --reset - contribution for kernel and s390-tools" right?

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-05-11 13:29 EDT-------
(In reply to comment #14)
> The commits landed in between in linux-next (not tagged yet, but that's
> fine).
> So it's all brand new stuff ...
> I think the chance it not very high that they are just cleanly
> cherry-pick-able - having the other PCI changes in mind, too.
>
> I guess you are thinking about backporting them to focal master-next?
> $ git clone
> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal
> --branch master-next --single-branch focal-master-next

Yes I agree. I will work with Pierre to provide backports. I think a HWE might be an option should we discuss what this would entail here or on another channel? The reason for opening this issue even before this hit Linus' tree or we have backports done was exactly this opening up of discussions how to best proceed with this.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-05-13 12:00 EDT-------
Hi Frank, so the good news is the backporting seems to require no changes except for fixing the context because the power management was removed upstream. I've now got a system running with the changes backported to focal master-next.

Still it's 13 patches (including my 2 UID / Domain allocation patches we are also tracking in other issues and one for a new port attribute that makes things apply cleanly but I can also remove that).
Would you prefer that I send these by mail to you or should I attach them to this issue?

Revision history for this message
Frank Heimes (fheimes) wrote :

Sounds good - I tried to cherry pick the commits once, but it failed - but I don't remember why.
Could be of course due to the power mgnt removal ...
(in comment #5 I just count 10 commits - and you mentioned 13)

In a call earlier today this was briefly discusses with Nicholas and Heinz-Werner.
My assumption was that this is mainly for the gt kernel, means could be applied to that only. But it turned out that this also requested/needed for the stock ubuntu-server kernel.

I hope there is on interference with the other pci related tickets we worked on.
They will land in the focal master-next tree soon - so probably best to double check the backports here on the updated tree.

Then we can only follow the SRU process.
Hence, I suggest that you please attach the backports (that as far as I could see are all architecture specific) - or mention if any of the commits are cherry-pick-able - and I'll apply, compile and submit them as SRU to the kernel teams mailing list and we have to discuss with the kernel team what's possible/acceptable.
Means business as usual (like with the other tickets, too).

Changed in ubuntu-z-systems:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
Changed in linux (Ubuntu):
assignee: Skipper Bug Screeners (skipper-screen-team) → Canonical Kernel Team (canonical-kernel-team)
status: New → Incomplete
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-05-14 04:19 EDT-------
It's now 12. I included the "s390/pci: Fix zpci_alloc_domain() over allocation" commit but that just landed on master-next.

Also I included the one I mentioned in that bugzilla.

s390/pci: Improve handling of unset UID

Both together allow things to apply more cleanly. Their code is basically
replaced by the multi-function series though.

As the second wasn't taken I'll include it as part of this series. Then there is an additional documentation only commit:

s390/pci: Documentation for zPCI

and a one line fixup

s390/pci: removes wrong PCI multifunction assignment

I'll add all of the patches here as attachments even if they applied clean just so we keep this together.

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: Improve handling of unset UID

------- Comment on attachment From <email address hidden> 2020-05-14 04:33 EDT-------

This patch isn't strictly part of the multi-function work and is in fact entirely replaced by it but it allows the latter to apply cleanly and matches upstream.

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: embedding hotplug_slot in zdev

------- Comment (attachment only) From <email address hidden> 2020-05-14 04:34 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : 390/pci: Expose new port attribute for PCIe functions

------- Comment on attachment From <email address hidden> 2020-05-14 04:38 EDT-------

This patch also isn't strictly part of the multi-function patch series
but it adds a member to the "struct zpci_dev" that we would otherwise
have to declare as reserved which is an unnecessary deviation from upstream
and will make thins not apply cleanly in the future.

It's ordered after the "s390/pci: embedding hotplug_slot in zdev" patch
to match upstream history even though that is already a preparation commit
for multi-functions.

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: adaptation of iommu to multifunction

------- Comment (attachment only) From <email address hidden> 2020-05-14 04:39 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: define kernel parameters for PCI multifunction

------- Comment (attachment only) From <email address hidden> 2020-05-14 04:39 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: define RID and RID available

------- Comment (attachment only) From <email address hidden> 2020-05-14 04:40 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: create zPCI bus

------- Comment (attachment only) From <email address hidden> 2020-05-14 04:41 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: adapt events for zbus

------- Comment (attachment only) From <email address hidden> 2020-05-14 04:41 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: Handling multifunctions

------- Comment (attachment only) From <email address hidden> 2020-05-14 04:42 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: Do not disable PF when VFs exist

------- Comment (attachment only) From <email address hidden> 2020-05-14 04:42 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: Documentation for zPCI

------- Comment (attachment only) From <email address hidden> 2020-05-14 04:43 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : s390/pci: removes wrong PCI multifunction assignment

------- Comment (attachment only) From <email address hidden> 2020-05-14 04:43 EDT-------

Revision history for this message
Frank Heimes (fheimes) wrote :

The backports seem to apply, compile and build fine.
The only little issue is that the backports do not come with full provenance, which is important for the Canonical kernel team.
Means that the 'Signed-off-by\|Reviewed-by\|Tested-by' lines from the upstream accepted commits need to be added to the corresponding backports, as well as a backport lines that includes the upstream commit id.
Here, especially the backport lines were all missing.
I've looked them up and added them now by hand, but would like to ask you to directly add them to the backports next time.

Revision history for this message
Frank Heimes (fheimes) wrote :

Kernel SRU request submitted:
https://lists.ubuntu.com/archives/kernel-team/2020-May/thread.html#110043
Updating status to 'In Progress'.

description: updated
Changed in linux (Ubuntu):
status: Incomplete → In Progress
Changed in ubuntu-z-systems:
status: Incomplete → In Progress
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2020-05-19 05:21 EDT-------
Technical issue:
Mellanox CX5 port multi-pathing is broken on s390x due to non-standard topology of PCI IDs (phys. and virtual)

Details
The Mellanox ConnectX5 Linux PCI driver (mlx5) implements a multi-path feature that can be used to combine multiple networking ports to improve performance and reliability. For that purpose, the mlx5 driver combines PCI functions based on topology information (the function number) as determined from their PCI ID.

Currently the Linux on Z PCI bus does not reflect PCI topology information in the PCI ID. As a result, the mlx5 multi-path function cannot be activated.

Revision history for this message
Frank Heimes (fheimes) wrote :

Based on comment #28 the bug description / SRU justification was updated.

description: updated
Revision history for this message
Frank Heimes (fheimes) wrote :

A test build is available at 'ppa:fheimes/tmp-s390x'.
( For more info see https://launchpad.net/~fheimes/+archive/ubuntu/tmp-s390x )
The kernel and supporting packages for this ticket are under "linux - 5.4.0-31.35ubuntu1"

Revision history for this message
Frank Heimes (fheimes) wrote :

@IBM Please can you test the patched kernel from the PPA and leave a quick feedback here if it works like expected?
This would lower the risk a bit and increase the confidence and would at the end help regarding the acceptance by the kernel team.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-05-20 06:22 EDT-------
(In reply to comment #37)
> @IBM Please can you test the patched kernel from the PPA and leave a quick
> feedback here if it works like expected?
> This would lower the risk a bit and increase the confidence and would at the
> end help regarding the acceptance by the kernel team.

Thanks for the fast turn around, I can confirm that this package from your PPA
works as expected enabling the correct multi-function enumeration.

But let me take this opportunity to talk about a related issue because

a) It is another reason these patches fix real problems and
b) It is needed to make full use of these patches when using SR-IOV
c) I want to give you this as a heads-up to consider during the discussion
of whether you take the patches discussed here.

echo 0 > /sys/bus/pci/devices/<mlx5_pf>/sriov_numvfs

With multiple PCI Virtual Functions (VFs) active, the drivers for the VFs just see the devices gone.
This of course only affects systems with PCI Physical Functions (none
at customers currently) and indeed the same happens without these patches
(just confirmed that again) so this isn't a regression.

The thing is, I have 2 patches queued for upstream that make this VF
shutdown as graceful as on x86_64.

These patches need to go on top of the patches discussed here as they
make use of the RID introduced with these patches. However
they also need a (very small) common code change. So I'm not sure
how we will handle those.

Revision history for this message
Frank Heimes (fheimes) wrote :

First of all thanks for testing the PPA.
I'm sure that helps in regard to the acceptance of the SRU.

For the additional two patches it's best to open a separate LP ticket - and upstream acceptance is of course crucial, too.
The common code change is quite critical (is it one of the two - or a third one?).
I assume that you tried to make the needed modifications as small and limited as possible, clear and traceable.
Since the these patches are based on one ones from above, I guess it's not possible to flag them upstream for an upstream release update - for 5.4 (at least the common code change)?!

Please let me know the commit title and/or IDs.

We have to have a deep look into it and a solid SRU justification....

Stefan Bader (smb)
Changed in linux (Ubuntu Focal):
importance: Undecided → Medium
status: New → In Progress
Changed in linux (Ubuntu Focal):
status: In Progress → Fix Committed
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
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-focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'.

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-focal
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-06-12 03:38 EDT-------
I verfied that this is working with 5.4.0-38-generic from Focal Proposed
including the interaction between this Issue and the PF/VF Linking.
Thank you for the great and quick cooperation!

Revision history for this message
Andrew Cloke (andrew-cloke) wrote :

Many thanks! Adjust tags.

tags: added: verification-done-focal
removed: verification-needed-focal
Revision history for this message
Andrew Cloke (andrew-cloke) wrote :

Many thanks! Adjusting tags.

Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (linux-oracle-5.4/5.4.0-1019.19~18.04.1)

All autopkgtests for the newly accepted linux-oracle-5.4 (5.4.0-1019.19~18.04.1) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

zfs-linux/unknown (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#linux-oracle-5.4

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

This bug was fixed in the package linux - 5.4.0-40.44

---------------
linux (5.4.0-40.44) focal; urgency=medium

  * linux-oem-5.6-tools-common and -tools-host should be dropped (LP: #1881120)
    - [Packaging] Add Conflicts/Replaces to remove linux-oem-5.6-tools-common and
      -tools-host

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

  * Slow send speed with Intel I219-V on Ubuntu 18.04.1 (LP: #1802691)
    - e1000e: Disable TSO for buffer overrun workaround

  * CVE-2020-0543
    - UBUNTU/SAUCE: x86/speculation/srbds: do not try to turn mitigation off when
      not supported

  * Realtek 8723DE [10ec:d723] subsystem [10ec:d738] disconnects unsolicitedly
    when Bluetooth is paired: Reason: 23=IEEE8021X_FAILED (LP: #1878147)
    - SAUCE: Revert "UBUNTU: SAUCE: rtw88: Move driver IQK to set channel before
      association for 11N chip"
    - SAUCE: Revert "UBUNTU: SAUCE: rtw88: fix rate for a while after being
      connected"
    - SAUCE: Revert "UBUNTU: SAUCE: rtw88: No retry and report for auth and assoc"
    - SAUCE: Revert "UBUNTU: SAUCE: rtw88: 8723d: Add coex support"
    - rtw88: add a debugfs entry to dump coex's info
    - rtw88: add a debugfs entry to enable/disable coex mechanism
    - rtw88: 8723d: Add coex support
    - SAUCE: rtw88: coex: 8723d: set antanna control owner
    - SAUCE: rtw88: coex: 8723d: handle BT inquiry cases
    - SAUCE: rtw88: fix EAPOL 4-way failure by finish IQK earlier

  * CPU stress test fails with focal kernel (LP: #1867900)
    - [Config] Disable hisi_sec2 temporarily

  * Enforce all config annotations (LP: #1879327)
    - [Config]: do not enforce CONFIG_VERSION_SIGNATURE
    - [Config]: prepare to enforce all
    - [Config]: enforce all config options

  * Focal update: v5.4.44 upstream stable release (LP: #1881927)
    - ax25: fix setsockopt(SO_BINDTODEVICE)
    - dpaa_eth: fix usage as DSA master, try 3
    - net: don't return invalid table id error when we fall back to PF_UNSPEC
    - net: dsa: mt7530: fix roaming from DSA user ports
    - net: ethernet: ti: cpsw: fix ASSERT_RTNL() warning during suspend
    - __netif_receive_skb_core: pass skb by reference
    - net: inet_csk: Fix so_reuseport bind-address cache in tb->fast*
    - net: ipip: fix wrong address family in init error path
    - net/mlx5: Add command entry handling completion
    - net: mvpp2: fix RX hashing for non-10G ports
    - net: nlmsg_cancel() if put fails for nhmsg
    - net: qrtr: Fix passing invalid reference to qrtr_local_enqueue()
    - net: revert "net: get rid of an signed integer overflow in
      ip_idents_reserve()"
    - net sched: fix reporting the first-time use timestamp
    - net/tls: fix race condition causing kernel panic
    - nexthop: Fix attribute checking for groups
    - r8152: support additional Microsoft Surface Ethernet Adapter variant
    - sctp: Don't add the shutdown timer if its already been added
    - sctp: Start shutdown on association restart if in SHUTDOWN-SENT state and
      socket is closed
    - tipc: block BH before using dst_cache
    - net/mlx5e: kTLS, Destroy key object after destroying the TIS
    - net/mlx5e: Fix inner tirs handling
    - net/m...

Changed in linux (Ubuntu Focal):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 5.4.0-42.46

---------------
linux (5.4.0-42.46) focal; urgency=medium

  * focal/linux: 5.4.0-42.46 -proposed tracker (LP: #1887069)

  * linux 4.15.0-109-generic network DoS regression vs -108 (LP: #1886668)
    - SAUCE: Revert "netprio_cgroup: Fix unlimited memory leak of v2 cgroups"

linux (5.4.0-41.45) focal; urgency=medium

  * focal/linux: 5.4.0-41.45 -proposed tracker (LP: #1885855)

  * Packaging resync (LP: #1786013)
    - update dkms package versions

  * CVE-2019-19642
    - kernel/relay.c: handle alloc_percpu returning NULL in relay_open

  * CVE-2019-16089
    - SAUCE: nbd_genl_status: null check for nla_nest_start

  * CVE-2020-11935
    - aufs: do not call i_readcount_inc()

  * ip_defrag.sh in net from ubuntu_kernel_selftests failed with 5.0 / 5.3 / 5.4
    kernel (LP: #1826848)
    - selftests: net: ip_defrag: ignore EPERM

  * Update lockdown patches (LP: #1884159)
    - SAUCE: acpi: disallow loading configfs acpi tables when locked down

  * seccomp_bpf fails on powerpc (LP: #1885757)
    - SAUCE: selftests/seccomp: fix ptrace tests on powerpc

  * Introduce the new NVIDIA 418-server and 440-server series, and update the
    current NVIDIA drivers (LP: #1881137)
    - [packaging] add signed modules for the 418-server and the 440-server
      flavours

 -- Khalid Elmously <email address hidden> Thu, 09 Jul 2020 19:50:26 -0400

Changed in linux (Ubuntu Groovy):
status: In Progress → Fix Released
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: Fix Committed → Fix Released
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2020-07-28 02:38 EDT-------
IBM bugzilla status-> closed, Fix Released with focal

To post a comment you must log in.