[PATCH V2 0/6][SRU][OEM-5.14/Jammy/OEM-5.17/Unstable] build backport-iwlwifi-dkms as linux-modules-iwlwifi-ABI

Dimitri John Ledkov dimitri.ledkov at canonical.com
Tue Apr 26 11:03:14 UTC 2022


As a side comment, this patch series highlights that we have some
obsolete and unused portions of our packaging:

wireguard has been mainlined, so jammy kernels do not need
do_dkms_wireguard bits. Also variables nvidia_desktop_series and
nvidia_server_series are assigned but never used, since the long
completed move to lrm/lrg/lrs.

Removing references to those things is probably kinetic only thing, as
these unused things are harmless.

-- 
okurrr,

Dimitri

On Fri, 22 Apr 2022 at 18:11, You-Sheng Yang <vicamo.yang at canonical.com> wrote:
>
> From: "You-Sheng Yang (vicamo)" <vicamo.yang at canonical.com>
>
> BugLink: https://bugs.launchpad.net/bugs/1969434
>
> [Impact]
>
> Intel AX211 iwlwifi -64 firmware may fail to init under reboot stress,
> and -67 is immune. FW API -64 supported by oem-5.14, and -67 in v5.16.
> Not reproducible on every platform with AX211 installed, and the chances
> of such failures vary from one to another.
>
> [Fix]
>
> A few solutions were considered. The very first one is to ask Intel to
> fix -64 firmware directly, and the answer is a solid no claimed -64 is
> not the planned production version of AX211.
>
> It's also possible to backport FW API from v5.16, but while iwlwifi FW
> API is more or less a black box to us and the new FW APIs also depends
> on updates on the wireless stack, this is going to be very risky and
> actually we had regressions before after such backports.
>
> The last viable solution is to run backport-iwlwifi-dkms >= rev 8580 on
> the effected platforms. This means oem-5.14 and its migration target,
> hwe-5.15 will not be able to drive this piece of hw flawlessly without
> backport-iwlwifi-dkms installed.
>
> However, while we need secureboot to be enabled on these platforms,
> backport-iwlwifi-dkms must also be signed somehow. There are two
> possible method to achieve this, too. One, to prebuild this dkms as zfs
> and v4l2loopback does. However, while backport-iwlwifi-dkms generates
> kernel modules with exactly the same name as the in-tree ones, when
> prebuilt, they'll be available directly from the linux-modules package
> and therefore overrides the in-tree ones always, turning the in-tree
> driver completely useless and risk the stability of all other generic
> installations.
>
> The second one is to build backport-iwlwifi-dkms as nvidia graphic
> drivers in the linux-restricted-modules source package. In this way,
> affected platforms may install the corresponding packages when needed
> without interfering others. However, l-r-m is for restricted modules
> that needs special care of redistribution of its binaries, and
> backport-iwlwifi-dkms is GPL licensed.
>
> Here a similar but simpler process in the main kernel tree is
> re-implemented. Two additional packages,
> linux-modules-MODULE-PKGVER-ABINUM-FLAVOUR and its meta package
> linux-modules-MODULE-FLAVOUR will be created.
>
> [Test Case]
>
> Test builds:
> ./jammy/amd64/linux-modules-iwlwifi-5.15.0-27-generic_5.15.0-27.28_amd64.deb
> ./jammy/amd64/linux-modules-iwlwifi-generic_5.15.0-27.28_amd64.deb
> ./unstable/amd64/linux-modules-iwlwifi-5.17.0-8-generic_5.17.0-8.8_amd64.deb
> ./unstable/amd64/linux-modules-iwlwifi-generic_5.17.0-8.8_amd64.deb
> ./oem-5.17/amd64/linux-modules-iwlwifi-5.17.0-1003-oem_5.17.0-1003.3_amd64.deb
> ./oem-5.17/amd64/linux-modules-iwlwifi-oem_5.17.0-1003.3_amd64.deb
> ./oem-5.14/amd64/linux-modules-iwlwifi-5.14.0-1033-oem_5.14.0-1033.36_amd64.deb
> ./oem-5.14/amd64/linux-modules-iwlwifi-oem_5.14.0-1033.36_amd64.deb
>
> [Where problems could occur]
>
> Different from nvidia packages built from l-r-m, the generated package
> names do not carry an additional short version string, e.g. nvidia-410,
> as there is no such necessity to build multiple versions of iwlwifi.
> The modules are installed to /lib/modules/<kver>/kernel/iwlwifi, not
> iwlwifi-9858/.
>
> V2:
> * extend debian/dkms-versions to carry all the module specific
>   parameters. Also rewrite debian/scripts/control-create a bit to lookup
>   module name automatically.
> * add arch=foo in debian/dkms-versions. This also removes do_<module>
>   settings in $DEBIAN/rules.d/<arch>.mk. Their initial values will be
>   assigned automatically if not already specified.
> * add rprovides=foo in debian/dkms-versions.
> * support dkms_include and dkms_exclude settings. When enlisted, a
>   specified module will become available to the current arch if not
>   explicitly excluded again in dkms_exclude.
> * rewrite those do_<module>_disable as well.
> * indentation and white spaces.
> * fix build failure when multiple standalone modules are involved.
> * bump backport-iwlwifi-dkms version.
> * remove do_standalone_dkms from V1 as we don't need it.
>
> You-Sheng Yang (vicamo) (6):
>   UBUNTU: [Packaging] refactor dkms-versions to carry modulename
>   UBUNTU: [Packaging] add debpath= in dkms-versions
>   UBUNTU: [Packaging] add rprovides= in dkms-versions
>   UBUNTU: [Packaging] add arch= in dkms-versions
>   UBUNTU: [Packaging] support build dkms as standalone package
>   UBUNTU: [Packaging] support building backport-iwlwifi-dkms as
>     standalone modules
>
>  debian.master/rules.d/amd64.mk       |  2 --
>  debian.master/rules.d/arm64.mk       |  1 -
>  debian.master/rules.d/ppc64el.mk     |  1 -
>  debian.master/rules.d/s390x.mk       |  2 --
>  debian/control.d/flavour-module.stub | 30 ++++++++++++++++++++
>  debian/dkms-versions                 |  5 ++--
>  debian/rules                         | 25 ++++++++---------
>  debian/rules.d/0-common-vars.mk      | 36 ++++++++++++++++++++++++
>  debian/rules.d/2-binary-arch.mk      | 42 ++++++++++++++++++++++------
>  debian/scripts/control-create        | 28 +++++++++++++++++++
>  10 files changed, 143 insertions(+), 29 deletions(-)
>  create mode 100644 debian/control.d/flavour-module.stub
>
> --
> 2.34.1
>
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team



More information about the kernel-team mailing list