| Message ID | 20220513131752.713273-1-vicamo.yang@canonical.com |
|---|---|
| Headers | show |
| Series | build backport-iwlwifi-dkms as linux-modules-iwlwifi-ABI | expand |
You-Sheng Yang kirjoitti 13.5.2022 klo 16.17: > From: "You-Sheng Yang (vicamo)" <vicamo.yang@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 (in linux-meta) will be created. > > [Test Case] > > Test builds: > > linux$ ls */*/*iwlwifi* > jammy/amd64/linux-modules-iwlwifi-5.15.0-2029-generic_5.15.0-2029.30+lp1969434.3_amd64.deb > oem-5.14/amd64/linux-modules-iwlwifi-5.14.0-2035-oem_5.14.0-2035.38+lp1969434.3_amd64.deb > oem-5.17/amd64/linux-modules-iwlwifi-5.17.0-2004-oem_5.17.0-2004.4+lp1969434.3_amd64.deb > unstable/amd64/linux-modules-iwlwifi-5.18.0-2002-generic_5.18.0-2002.2+lp1969434.3_amd64.deb > > meta$ ls */*iwlwifi* > jammy/linux-modules-iwlwifi-generic_5.15.0.29.32+lp1969434.3_amd64.deb > jammy/linux-modules-iwlwifi-generic-hwe-22.04_5.15.0.29.32+lp1969434.3_amd64.deb > jammy/linux-modules-iwlwifi-generic-hwe-22.04-edge_5.15.0.29.32+lp1969434.3_amd64.deb > jammy/linux-modules-iwlwifi-virtual_5.15.0.29.32+lp1969434.3_amd64.deb > jammy/linux-modules-iwlwifi-virtual-hwe-22.04_5.15.0.29.32+lp1969434.3_amd64.deb > jammy/linux-modules-iwlwifi-virtual-hwe-22.04-edge_5.15.0.29.32+lp1969434.3_amd64.deb > oem-5.14/linux-modules-iwlwifi-oem-20.04_5.14.0.1035.32+lp1969434.3_amd64.deb > oem-5.14/linux-modules-iwlwifi-oem-20.04d_5.14.0.1035.32+lp1969434.3_amd64.deb > oem-5.17/linux-modules-iwlwifi-oem-22.04_5.17.0.1004.4+lp1969434.3_amd64.deb > oem-5.17/linux-modules-iwlwifi-oem-22.04a_5.17.0.1004.4+lp1969434.3_amd64.deb > unstable/linux-modules-iwlwifi-generic-wip_5.18.0.2.10+lp1969434.3_amd64.deb > unstable/linux-modules-iwlwifi-virtual-wip_5.18.0.2.10+lp1969434.3_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>/ubuntu/iwlwifi, not > iwlwifi-9858/. > > V4: > * support multiple debpath parameters > > V3: > * move meta pacakge generation to linux-meta, and update kernel-versions > according to the versions required. > * allow %package%, %version%, %module% in debpath parameter, so that no > additional work introduced in kernel-versions update-dkms-versions > script. Also handle version epoch. > * bump versions for unstable only due to build breaks against v5.18-rcX. > * fix dkms_exclude/dkms_include. > * introduction type= parameter with currently 2 possible values, > standalone and built-in (default). > * use "any" instead of "__all__" for unspecified module architecture. > * introduce dkms_foo_subdir that is used to install built-in modules in > kernel/ and standalone ones in ubuntu/. > * and since dkms-versions of oem-5.14 is tracking that of impish, > dkms-versions/impish:main is updated with additional parameters. > > 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) (3): > UBUNTU: [Packaging] support standalone dkms module builds > UBUNTU: debian/dkms-versions -- update from kernel-versions > (main/master) > UBUNTU: [Packaging] drop do_<mod> arch specific configs > > 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 | 19 +++++++++++ > debian/dkms-versions | 5 +-- > debian/rules | 25 +++++++-------- > debian/rules.d/0-common-vars.mk | 47 ++++++++++++++++++++++++++++ > debian/rules.d/2-binary-arch.mk | 36 ++++++++++++++++----- > debian/scripts/control-create | 27 ++++++++++++++++ > 10 files changed, 136 insertions(+), 29 deletions(-) > create mode 100644 debian/control.d/flavour-module.stub > While the parts shared with other kernels aren't fully settled yet, I've applied this to oem-5.14 for the respin that we need (and oem-5.17 for the current cycle). Any details can be changed later. Thanks!
The kernel-versions portion of the changes has been extensively reviewed in terms of new keywords being introduced, and how they interact with current kernels with existing & the newly introduced packaging. The approach taken is flexible, easy to maintain, and improve/extend over time. I did not like the possibility of these changes introducing unexpected new abi changes in some of our non-hwe kernels (i.e. cloud kernels). Thus I have slightly modified the mappings, to ensure that only kernels targeting hwe consumer devices have the possibility to build the newly added kernel modules. See the other patch i sent to the mailing list. This enables all relevant kernels to run `./update-dkms-versions --sru-cycle master` to vendor updated kernel-versions automatically & apply the other changes to enable building these new modules.
The kernel-versions changes got applied to the default repository, and updated in kinetic:linux-unstable. Manual toggles to turn off zfs & v4l2loopback builds reverted. Changes to start building additional backport module during main package build applied. Still TODO from me to finish review and apply: - meta changes to kinetic:linux-unstable - drop the now redundant do_zfs settings for unstable kernel
From: "You-Sheng Yang (vicamo)" <vicamo.yang@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 (in linux-meta) will be created. [Test Case] Test builds: linux$ ls */*/*iwlwifi* jammy/amd64/linux-modules-iwlwifi-5.15.0-2029-generic_5.15.0-2029.30+lp1969434.3_amd64.deb oem-5.14/amd64/linux-modules-iwlwifi-5.14.0-2035-oem_5.14.0-2035.38+lp1969434.3_amd64.deb oem-5.17/amd64/linux-modules-iwlwifi-5.17.0-2004-oem_5.17.0-2004.4+lp1969434.3_amd64.deb unstable/amd64/linux-modules-iwlwifi-5.18.0-2002-generic_5.18.0-2002.2+lp1969434.3_amd64.deb meta$ ls */*iwlwifi* jammy/linux-modules-iwlwifi-generic_5.15.0.29.32+lp1969434.3_amd64.deb jammy/linux-modules-iwlwifi-generic-hwe-22.04_5.15.0.29.32+lp1969434.3_amd64.deb jammy/linux-modules-iwlwifi-generic-hwe-22.04-edge_5.15.0.29.32+lp1969434.3_amd64.deb jammy/linux-modules-iwlwifi-virtual_5.15.0.29.32+lp1969434.3_amd64.deb jammy/linux-modules-iwlwifi-virtual-hwe-22.04_5.15.0.29.32+lp1969434.3_amd64.deb jammy/linux-modules-iwlwifi-virtual-hwe-22.04-edge_5.15.0.29.32+lp1969434.3_amd64.deb oem-5.14/linux-modules-iwlwifi-oem-20.04_5.14.0.1035.32+lp1969434.3_amd64.deb oem-5.14/linux-modules-iwlwifi-oem-20.04d_5.14.0.1035.32+lp1969434.3_amd64.deb oem-5.17/linux-modules-iwlwifi-oem-22.04_5.17.0.1004.4+lp1969434.3_amd64.deb oem-5.17/linux-modules-iwlwifi-oem-22.04a_5.17.0.1004.4+lp1969434.3_amd64.deb unstable/linux-modules-iwlwifi-generic-wip_5.18.0.2.10+lp1969434.3_amd64.deb unstable/linux-modules-iwlwifi-virtual-wip_5.18.0.2.10+lp1969434.3_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>/ubuntu/iwlwifi, not iwlwifi-9858/. V4: * support multiple debpath parameters V3: * move meta pacakge generation to linux-meta, and update kernel-versions according to the versions required. * allow %package%, %version%, %module% in debpath parameter, so that no additional work introduced in kernel-versions update-dkms-versions script. Also handle version epoch. * bump versions for unstable only due to build breaks against v5.18-rcX. * fix dkms_exclude/dkms_include. * introduction type= parameter with currently 2 possible values, standalone and built-in (default). * use "any" instead of "__all__" for unspecified module architecture. * introduce dkms_foo_subdir that is used to install built-in modules in kernel/ and standalone ones in ubuntu/. * and since dkms-versions of oem-5.14 is tracking that of impish, dkms-versions/impish:main is updated with additional parameters. 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) (3): UBUNTU: [Packaging] support standalone dkms module builds UBUNTU: debian/dkms-versions -- update from kernel-versions (main/master) UBUNTU: [Packaging] drop do_<mod> arch specific configs 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 | 19 +++++++++++ debian/dkms-versions | 5 +-- debian/rules | 25 +++++++-------- debian/rules.d/0-common-vars.mk | 47 ++++++++++++++++++++++++++++ debian/rules.d/2-binary-arch.mk | 36 ++++++++++++++++----- debian/scripts/control-create | 27 ++++++++++++++++ 10 files changed, 136 insertions(+), 29 deletions(-) create mode 100644 debian/control.d/flavour-module.stub