Can you guys jump to latest kernel 6.3 for ubuntu 22.04?
it has tremendous speed up for io_uring applications.
The 22.04.4 release in Q1 24 will have a kernel later than 6.3. Or also the 23.10 release in Q4 23.
I am trying to build kernel 6.2.0-26 on jammy for amd64-generic with unchanged configuration. Unfortunately, it does not run through, tools/bpf/bpftool/vmlinux cannot be found.
For the build I have installed the following packages:
libncurses-dev gawk flex bison openssl libssl-dev dkms libelf-dev libudev-dev libpci-dev debhelper binutils-dev python-is-python3 libiberty-dev pahole libreadline-dev llvm ubuntu-dev-tools libdw-dev systemtap-sdt-dev libunwind-dev libslang2-dev libzstd-dev libcap-dev libbabeltrace-ctf-dev openjdk-8-jdk libtraceevent-dev
Additional packages for Rust:
rustc cargo llvm-15 lld-15 clang-15 wasi-libc bindgen librust-core-foundation-dev rust-src
The build process is:
$ make olddefconfig
[...]
# using defaults found in /boot/config-6.2.0-26-generic
#
#
# configuration written to .config
$ LANG=C fakeroot debian/rules clean
[...]
$ LANG=C fakeroot debian/rules binary
[...]
CC util/expr-flex.o
CC pmu-events/pmu-events.o
LD util/intel-pt-decoder/perf-in.o
LD util/perf-in.o
LD pmu-events/pmu-events-in.o
LD perf-in.o
LINK perf
make[1]: Leaving directory '/[...]/debian/build/tools-perarch/tools/perf'
mv /[...]/debian/build/tools-perarch/tools/bpf/bpftool/vmlinux /[...]/debian/build/tools-perarch/vmlinux
mv: cannot stat '/[...]/debian/build/tools-perarch/tools/bpf/bpftool/vmlinux': No such file or directory
make: *** [debian/rules.d/2-binary-arch.mk:749: /[...]/debian/stamps/stamp-build-perarch] Error 1Can you please try
mk-sbuild jammy
pull-lp-source linux-hwe-6.2 jammy
sbuild -A -d jammy ./linux-hwe-6.2*.dsc
And does that work?
Separately, you can also try this instructions instead Kernel/BuildYourOwnKernel - Ubuntu Wiki
Note that ubuntu kernels do not use âmake olddefconfigâ to compile the kernel, instead we use annotations, and you can use commands like fakeroot debian/rules editconfigs if you want to change them.
mk-sbuild asked me for an email address, and it seemed mandatory. I have put a valid one, leading to:
Error reading configuration: MAILPROG binary â/usr/sbin/sendmailâ does not exist.
I could figure out that I can set $mailto = ''; in .sbuildrc, more appropriate for a local build.
The second command ran through, but I had to cd to directory level one up compared to $build_dir and $log_dir before executing it to have some order.
The last command leads to the following output, and I do not know how to deal with it:
sbuild (Debian sbuild) 0.81.2ubuntu6 (16 February 2022) on malah
+==============================================================================+
| linux-hwe-6.2 6.2.0-32.32~22.04.1 (amd64) Tue, 22 Aug 2023 01:45:07 +0000 |
+==============================================================================+
Package: linux-hwe-6.2
Version: 6.2.0-32.32~22.04.1
Source Version: 6.2.0-32.32~22.04.1
Distribution: jammy
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary
W: No chroots are defined in â/etc/schroot/schroot.confâ or â/etc/schroot/chroot.dâ
E: Error creating chroot
+------------------------------------------------------------------------------+
| Summary |
+------------------------------------------------------------------------------+
Build Architecture: amd64
Build Type: binary
Build-Space: 0
Build-Time: 0
Distribution: jammy
Fail-Stage: create-session
Host Architecture: amd64
Install-Time: 0
Job: ./linux-hwe-6.2_6.2.0-32.32~22.04.1.dsc
Machine Architecture: amd64
Package: linux-hwe-6.2
Package-Time: 0
Source-Version: 6.2.0-32.32~22.04.1
Space: 0
Status: failed
Version: 6.2.0-32.32~22.04.1
--------------------------------------------------------------------------------
Finished at 2023-08-22T01:45:07Z
Build needed 00:00:00, 0k disk space
E: Error creating chroot
It seems mk-sbuild jammy has not been completed in full with all dependencies installed. Meaning you donât yet have a build chroot setup for jammy. Please try running mk-sbuild jammy until it is successful. Last execution likely only installed build-dependencies, and added your account to an sbuild group.
1 Like
I have managed to build the kernel successfully 
after repeating mk-sbuild jammy and then
$ sbuild -A -d jammy ./linux-hwe-6.2*.dsc
sbuild (Debian sbuild) 0.81.2ubuntu6 (16 February 2022) on malah
+==============================================================================+
| linux-hwe-6.2 6.2.0-32.32~22.04.1 (amd64) Tue, 22 Aug 2023 22:16:48 +0000 |
+==============================================================================+
Package: linux-hwe-6.2
Version: 6.2.0-32.32~22.04.1
Source Version: 6.2.0-32.32~22.04.1
Distribution: jammy
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary
[...]
I: Lintian run was successful.
+------------------------------------------------------------------------------+
| Post Build |
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
| Cleanup |
+------------------------------------------------------------------------------+
Purging /<<BUILDDIR>>
Not cleaning session: cloned chroot in use
+------------------------------------------------------------------------------+
| Summary |
+------------------------------------------------------------------------------+
Build Architecture: amd64
Build Type: binary
Build-Space: 28895096
Build-Time: 1288
Distribution: jammy
Host Architecture: amd64
Install-Time: 201
Job: ./linux-hwe-6.2_6.2.0-32.32~22.04.1.dsc
Lintian: warn
Machine Architecture: amd64
Package: linux-hwe-6.2
Package-Time: 1552
Source-Version: 6.2.0-32.32~22.04.1
Space: 28895096
Status: successful
Version: 6.2.0-32.32~22.04.1
--------------------------------------------------------------------------------
Finished at 2023-08-22T22:42:40Z
Build needed 00:25:52, 28895096k disk space
Is there a way to mark the build so that it becomes an isolated installation, not replaced by updates and not disturbing the rest of the system? It would be nice to have dkms support for it, so that for example nvidia.ko is built for it automatically during update, and a GRUB entry where it can reside independently of other entries. Just untouched by any update/autoremove mechanism.
I would like to build one specific module more often with ongoing changes, snd-usb-audio.ko, but without building everything again and waiting for half an hour. That module resides in linux-modules-extra-6.2.0-32-generic_6.2.0-32.32~22.04.1_amd64.deb. Is there a way to keep the intermediate files from the build so that some kind of âmakeâ can be applied? The turnaround time shall be low, I would just replace the module in the filesystem without tampering with .deb archives. I can imagine that the exact build environment needs to be adhered to, so presumably it has to happen inside schroot as well.
Btw, the Lintian pass took so long that I nearly stopped the process. It would be fine to have some kind of progress indicator, like a dot every 30s. htop showed that only one CPU core was used. Maybe someone can verify this observation.
Congratulations!
All of that is possible, but not advisable. This is kernel hacking / engineering. I would not directly advise you on how to achieve all of the above, because it will lead to an insecure system. Security patches will not be applied, likely secureboot is disabled, lockdown removed, the system becomes instantly trivial to attack, and will progressively become more insecure with time. So I am leaving these requests explicitly unanswered. But you can figure all of these things yourself by reading various documentation about apt, grub, package installation etc. There are many ways to achieve all that.
Can you please explain more about this? Are you patching it to fix issues? Can you share those patches and submit them to the upstream maintainer of the sound / sound-usb subsystem? Are you hardware vendor adding more support? Have you checked all the paramemters of that module that one can tweak at runtime? Is there anything Ubuntu able to patch in that module to keep it generic, but also usable for your purposes? Canonical Kernel team can adopt certain out-of-tree patches or redirect to request getting them merged upstream.
Standard methods are available and usable, for example setting up ccache integration with sbuild and using chroots without updates; or for example starting a persistent named schroot session and simply keeping it around entering it and reusing its state. Etc.
There are config and command-line options to skip lintian pass. Note that lintian is targetted at human developers of the distribution to observe / read / fix, if you have no intentions of doing that you can skip running it. Especially if no actions will be taken based on its results.
1 Like
I do not want to have an insecure system. It would be best to merge updates into the build and keep it current. Conflicts may arise, and they have to be dealt with. It is totally acceptable to do this, and easier for everyone when a local patch gets merged upstream.
I have a piece of hardware here, bought second-hand. It is a Presonus Studio 1810 audio interface. I tried it on Windows 10 first, where it worked well, and then left it on and booted Ubuntu 22.04. Firefox was quite unresponsive, so that it was unusable. I thought that the last update of the web browser led to an issue. But then I saw a spamming of the following error message in /var/log/syslog:
Aug 20 16:40:59 malah kernel: [15092.601784] usb 1-2: 1:3: usb_set_interface failed (-32)
After switching off the audio interface, the system was responsive again.
I researched the differences between the 1810 model and the newer and supported 1810c model. 1810c has a USB-C connector, but uses USB 2.0 bus protocol. The colors have changed, and the device ID. Firstable I want to test a quick fix, setting the device ID to the old model.
Coming to my mind is a desire to have discussion forums for subsytems, where maintainers are present, and upstream of course, for sharing knowledge. Not just for patch review/merge.
But as a first step I want to test the newly built kernel with changed device ID.
$ sudo dpkg -EGi linux-image-unsigned-6.2.0-32-generic_6.2.0-32.32~22.04.1_amd64.deb linux-modules-6.2.0-32-generic_6.2.0-32.32~22.04.1_amd64.deb linux-modules-extra-6.2.0-32-generic_6.2.0-32.32~22.04.1_amd64.deb linux-headers-6.2.0-32-generic_6.2.0-32.32~22.04.1_amd64.deb
All goes well, but linux-headers-6.2.0-32-generic_6.2.0-32.32~22.04.1_amd64.deb depends on linux-hwe-6.2-headers-6.2.0-32.deb which is not available. Package status: iU
$ sudo dkms install -m nvidia -v 535.86.05 -k 6.2.0-32-generic
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area...
unset ARCH; [ ! -h /usr/bin/cc ] && export CC=/usr/bin/gcc; env NV_VERBOSE=1 'make' -j16 NV_EXCLUDE_BUILD_MODULES='' KERNEL_UNAME=6.2.0-32-generic IGNORE_XEN_PRESENCE=1 IGNORE_CC_MISMATCH=1 SYSSRC=/lib/modules/6.2.0-32-generic/build LD=/usr/bin/ld.bfd CONFIG_X86_KERNEL_IBT= modules...(bad exit status: 2)
ERROR (dkms apport): kernel package linux-headers-6.2.0-32-generic is not supported
Error! Bad return status for module build on kernel: 6.2.0-32-generic (x86_64)
Consult /var/lib/dkms/nvidia/535.86.05/build/make.log for more information.
make.log:
DKMS make.log for nvidia-535.86.05 for kernel 6.2.0-32-generic (x86_64)
Do 24. Aug 00:53:05 CEST 2023
make[1]: Entering directory '/usr/src/linux-headers-6.2.0-32-generic'
Makefile:1109: scripts/Makefile.ubsan: No such file or directory
make[1]: *** No rule to make target 'scripts/Makefile.ubsan'. Stop.
make[1]: Leaving directory '/usr/src/linux-headers-6.2.0-32-generic'
make: *** [Makefile:82: modules] Error 2
1. Build vanilla kernel
I use a vanilla kernel from kernel.org and omit packages. To avoid name collision I use kernel 6.4.11. As a base I used the config from Ubuntu kernel config-6.2.0-26-generic. It led to a build error, which I could resolve by following this guide: https://phoenixnap.com/kb/build-linux-kernel.
This halves the build time to about 12 min. make localmodconfig would be even better, but the kernel was already built.
$ cd linux-6.4.11-presonus1810
$ cp /boot/config-6.2.0-26-generic .config
$ make oldconfig
$ make -j$(nproc) 2>&1 | tee make.log
$ scripts/config --disable SYSTEM_TRUSTED_KEYS
$ scripts/config --disable SYSTEM_REVOCATION_KEYS
$ make -j$(nproc) 2>&1 | tee make2.log
$ sudo make modules_install
goes to /lib/modules/6.4.11
$ sudo make install
$ sudo ~/sysadmin/virtualization/vfio/initramfs_without_vfio-pci.sh 6.4.11
Although it is a vanilla kernel, dkms is started automatically and failed to build the nvidia.ko module. I know already that 6.4 is too far ahead for this to happen at the moment. Furthermore, GRUB configuration is updated automatically. A pleasant surprise.
2. Reduce boot/test time
Because I can use aplay/arecord/amixer for testing, I do not need gdm. Runlevel 3 is enough.
The GRUB command line is minimal: usbcore.autosuspend=-1 3
I use the usbcore configuration because of my Android smartphone to avoid disconnect during USB usage. Not a proper solution, but this is another issue. For tinkering with a USB driver it is not bad to keep it, for as long as this aspect is not in focus of testing.
I have two graphics cards and cannot set the big one as secondary GPU. To avoid input switch on my monitor and reduce turnaround time further, I disabled vfio-pci for just this kernel. Since 6.2 vfio-pci is built as a module (like Arch Linux), so it is not enough to change the kernel command line to disable it. I have to tinker with initramfs configuration:
initramfs_without_vfio-pci.sh:
#!/bin/bash
# to be run as root
if [ $# -ne 1 ]; then
echo "Usage: $0 <kernel name>, i. e. $0 6.4.11"
exit 1
fi
kernel=$1
if ! [ -d "/lib/modules/$kernel" ]; then
echo kernel $kernel not found
exit 2
fi
echo "disable vfio module"
chmod a-x /etc/initramfs-tools/scripts/init-top/vfio.sh
sed -i 's/vfio/#vfio/' /etc/initramfs-tools/modules
echo "update initramfs without vfio for $kernel"
update-initramfs -u -k $kernel
echo "enable vfio module"
sed -i 's/#vfio/vfio/' /etc/initramfs-tools/modules
chmod a+x /etc/initramfs-tools/scripts/init-top/vfio.sh
exit 0
GRUB is not cooperative either, with the all-or-nothing approach. I only want kernel 6.4.11 to run with virtualization support disabled. It was quite a bit of tweaking to let GRUB make an exception.
Added to /etc/default/grub:
export GRUB_CMDLINE_LINUX_2="usbcore.autosuspend=-1 3"
export KERNEL_RUNLVL_3="6.4.11"
Changed parts of /etc/grub.d/10_linux:
if [ "x$is_top_level" = xtrue ] && [ "x${GRUB_DISABLE_SUBMENU}" != xtrue ]; then
if [ "${version}" != "${KERNEL_RUNLVL_3}" ]; then
linux_entry "${OS}" "${version}" simple \
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
else
linux_entry "${OS} text" "${version}" simple \
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_2}"
fi
and copying the code to the advanced section (important to remember!):
if [ "${version}" != "${KERNEL_RUNLVL_3}" ]; then
linux_entry "${OS}" "${version}" advanced \
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
else
linux_entry "${OS} text" "${version}" advanced \
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_2}"
fi
A look at /boot/grub/grub.cfg shows that everything is fine.
3. Test vanilla kernel
Aug 25 22:29:50 malah kernel: [ 133.573922] usb 1-2: 1:3: usb_set_interface failed (-32)
This is called repeatedly, for whatever reason. Printing once âUSB Audio: Presonus 1810 is not supportedâ would be better than freezing the system. Such messages could be shown as notification so that the user can switch the device off to save power when running Linux.
4. Patch kernel
But I want to see what happens if I let USB device 194f:0106 accepted:
diff -ru linux-6.4.11/sound/usb/format.c linux-6.4.11-presonus1810/sound/usb/format.c
--- linux-6.4.11/sound/usb/format.c 2023-08-16 18:32:31.000000000 +0200
+++ linux-6.4.11-presonus1810/sound/usb/format.c 2023-08-26 00:02:32.284648039 +0200
@@ -378,8 +378,8 @@
for (rate = min; rate <= max; rate += res) {
- /* Filter out invalid rates on Presonus Studio 1810c */
- if (chip->usb_id == USB_ID(0x194f, 0x010c) &&
+ /* Filter out invalid rates on Presonus Studio 1810 and 1810c */
+ if ((chip->usb_id == USB_ID(0x194f, 0x0106) || chip->usb_id == USB_ID(0x194f, 0x010c)) &&
!s1810c_valid_sample_rate(fp, rate))
goto skip_rate;
diff -ru linux-6.4.11/sound/usb/mixer_quirks.c linux-6.4.11-presonus1810/sound/usb/mixer_quirks.c
--- linux-6.4.11/sound/usb/mixer_quirks.c 2023-08-16 18:32:31.000000000 +0200
+++ linux-6.4.11-presonus1810/sound/usb/mixer_quirks.c 2023-08-26 00:09:52.699114926 +0200
@@ -3440,6 +3440,9 @@
err = snd_rme_controls_create(mixer);
break;
+ case USB_ID(0x194f, 0x0106): /* Presonus Studio 1810 */
+ err = snd_sc1810_init_mixer(mixer);
+ break;
case USB_ID(0x194f, 0x010c): /* Presonus Studio 1810c */
err = snd_sc1810_init_mixer(mixer);
break;
diff -ru linux-6.4.11/sound/usb/mixer_s1810c.c linux-6.4.11-presonus1810/sound/usb/mixer_s1810c.c
--- linux-6.4.11/sound/usb/mixer_s1810c.c 2023-08-16 18:32:31.000000000 +0200
+++ linux-6.4.11-presonus1810/sound/usb/mixer_s1810c.c 2023-08-26 00:12:00.547596670 +0200
@@ -552,7 +552,7 @@
return 0;
dev_info(&dev->dev,
- "Presonus Studio 1810c, device_setup: %u\n", chip->setup);
+ "Presonus Studio 1810/1810c, device_setup: %u\n", chip->setup);
if (chip->setup == 1)
dev_info(&dev->dev, "(8out/18in @ 48kHz)\n");
else if (chip->setup == 2)
diff -ru linux-6.4.11/sound/usb/quirks.c linux-6.4.11-presonus1810/sound/usb/quirks.c
--- linux-6.4.11/sound/usb/quirks.c 2023-08-16 18:32:31.000000000 +0200
+++ linux-6.4.11-presonus1810/sound/usb/quirks.c 2023-08-26 00:04:22.261206796 +0200
@@ -1549,8 +1549,8 @@
/* fasttrackpro usb: skip altsets incompatible with device_setup */
if (chip->usb_id == USB_ID(0x0763, 0x2012))
return fasttrackpro_skip_setting_quirk(chip, iface, altno);
- /* presonus studio 1810c: skip altsets incompatible with device_setup */
- if (chip->usb_id == USB_ID(0x194f, 0x010c))
+ /* presonus studio 1810/1810c: skip altsets incompatible with device_setup */
+ if (chip->usb_id == USB_ID(0x194f, 0x0106) || chip->usb_id == USB_ID(0x194f, 0x010c))
return s1810c_skip_setting_quirk(chip, iface, altno);
5. Rebuild and install module
$ make scripts prepare modules_prepare
[...]
$ make -C . M=sound/usb
CC [M] sound/usb/format.o
CC [M] sound/usb/mixer_quirks.o
CC [M] sound/usb/mixer_s1810c.o
CC [M] sound/usb/quirks.o
LD [M] sound/usb/snd-usb-audio.o
MODPOST sound/usb/Module.symvers
CC [M] sound/usb/snd-usb-audio.mod.o
LD [M] sound/usb/snd-usb-audio.ko
BTF [M] sound/usb/snd-usb-audio.ko
CC [M] sound/usb/snd-usbmidi-lib.mod.o
LD [M] sound/usb/snd-usbmidi-lib.ko
BTF [M] sound/usb/snd-usbmidi-lib.ko
[...]
$ sudo cp -a --no-preserve=ownership sound/usb/snd-usb-audio.ko sound/usb/snd-usbmidi-lib.ko /lib/modules/6.4.11/kernel/sound/usb/
6. Test modified kernel
I have switched on the audio interface, nothing else.
Aug 26 00:45:42 malah kernel: [ 30.464783] usb 1-2: new high-speed USB device number 2 using xhci_hcd
Aug 26 00:45:42 malah kernel: [ 30.615563] usb 1-2: New USB device found, idVendor=194f, idProduct=0106, bcdDevice= 2.5
1
Aug 26 00:45:42 malah kernel: [ 30.615571] usb 1-2: New USB device strings: Mfr=1, Product=3, SerialNumber=2
Aug 26 00:45:42 malah kernel: [ 30.615574] usb 1-2: Product: Studio 1810
Aug 26 00:45:42 malah kernel: [ 30.615578] usb 1-2: Manufacturer: PreSonus
Aug 26 00:45:42 malah kernel: [ 30.615581] usb 1-2: SerialNumber: <hidden>
Aug 26 00:45:42 malah kernel: [ 30.974956] usb 1-2: Presonus Studio 1810/1810c, device_setup: 0
Aug 26 00:45:42 malah kernel: [ 30.974963] usb 1-2: (8out/14in @ 96kHz)
Looks fine so far.
Aug 26 00:45:43 malah kernel: [ 31.555187] ------------[ cut here ]------------
Aug 26 00:45:43 malah kernel: [ 31.555191] usb 1-2: BOGUS control dir, pipe 80000280 doesn't match bRequestType 40
Aug 26 00:45:43 malah kernel: [ 31.555199] WARNING: CPU: 1 PID: 1872 at drivers/usb/core/urb.c:411 usb_submit_urb+0x64b
/0x700
Aug 26 00:45:43 malah kernel: [ 31.555207] Modules linked in: xt_CHECKSUM xt_MASQUERADE nft_chain_nat nf_nat bridge stp
llc ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt ipt_REJECT nf_reject_ipv4 xt_LOG nf_log_syslog xt_comment xt_multiport nft_
limit xt_limit xt_addrtype xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables intel_r
apl_msr intel_rapl_common amd64_edac edac_mce_amd kvm_amd snd_hda_codec_hdmi libcrc32c nfnetlink binfmt_misc snd_usb_audi
o(OE) snd_hda_intel kvm snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_virtuoso snd_oxygen_lib snd_us
bmidi_lib(OE) snd_hwdep snd_mpu401_uart uvcvideo nls_iso8859_1 snd_pcm videobuf2_vmalloc uvc snd_seq_midi videobuf2_memop
s snd_seq_midi_event videobuf2_v4l2 nfsd snd_rawmidi videodev irqbypass crct10dif_pclmul polyval_clmulni snd_seq polyval_
generic ghash_clmulni_intel sha512_ssse3 asus_nb_wmi eeepc_wmi aesni_intel asus_wmi snd_seq_device snd_timer crypto_simd
ledtrig_audio videobuf2_common cryptd sparse_keymap platform_profile asus_ec_sensors mc rapl
Aug 26 00:45:43 malah kernel: [ 31.555300] auth_rpcgss ccp input_leds joydev snd video wmi_bmof k10temp soundcore nfs_
acl lockd mac_hid grace sch_fq_codel drm sunrpc msr parport_pc ppdev lp parport ramoops reed_solomon pstore_blk pstore_zo
ne efi_pstore ip_tables x_tables autofs4 hid_microsoft ff_memless hid_generic usbhid hid ucsi_ccg typec_ucsi nvme typec i
gc crc32_pclmul nvme_core ahci i2c_piix4 i2c_nvidia_gpu xhci_pci libahci i2c_ccgx_ucsi xhci_pci_renesas nvme_common wmi
Aug 26 00:45:43 malah kernel: [ 31.555356] CPU: 1 PID: 1872 Comm: pulseaudio Tainted: G OE 6.4.11 #1
Aug 26 00:45:43 malah kernel: [ 31.555360] Hardware name: ASUS System Product Name/ProArt X570-CREATOR WIFI, BIOS 1201
04/19/2023
Aug 26 00:45:43 malah kernel: [ 31.555361] RIP: 0010:usb_submit_urb+0x64b/0x700
Aug 26 00:45:43 malah kernel: [ 31.555365] Code: 48 89 55 b8 89 4d c0 44 89 45 d0 e8 9f 1d ec ff 44 8b 45 d0 8b 4d c0 4
8 c7 c7 58 4f 5e 8a 48 8b 55 b8 48 89 c6 e8 85 66 50 ff <0f> 0b 44 8b 5d b4 e9 59 fc ff ff 0f b6 1d 88 85 9d 01 80 fb 01
0f
Aug 26 00:45:43 malah kernel: [ 31.555368] RSP: 0018:ffffb1e3c30ef9d8 EFLAGS: 00010292
Aug 26 00:45:43 malah kernel: [ 31.555371] RAX: 0000000000000000 RBX: ffff95f73b585550 RCX: 0000000000000000
Aug 26 00:45:43 malah kernel: [ 31.555373] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
Aug 26 00:45:43 malah kernel: [ 31.555374] RBP: ffffb1e3c30efa28 R08: 0000000000000000 R09: 0000000000000000
Aug 26 00:45:43 malah kernel: [ 31.555376] R10: 0000000000000000 R11: 0000000000000000 R12: ffff95f73fe7c858
Aug 26 00:45:43 malah kernel: [ 31.555378] R13: ffff95f73fe7c800 R14: ffff95f6c6f29440 R15: 0000000000000000
Aug 26 00:45:43 malah kernel: [ 31.555380] FS: 00007f9d26bf8080(0000) GS:ffff9605aea40000(0000) knlGS:0000000000000000
Aug 26 00:45:43 malah kernel: [ 31.555382] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 26 00:45:43 malah kernel: [ 31.555384] CR2: 00005618fe3ff578 CR3: 000000017b0b0000 CR4: 0000000000750ee0
Aug 26 00:45:43 malah kernel: [ 31.555386] PKRU: 55555554
Aug 26 00:45:43 malah kernel: [ 31.555387] Call Trace:
Aug 26 00:45:43 malah kernel: [ 31.555389] <TASK>
Aug 26 00:45:43 malah kernel: [ 31.555393] ? show_regs+0x72/0x90
Aug 26 00:45:43 malah kernel: [ 31.555398] ? usb_submit_urb+0x64b/0x700
Aug 26 00:45:43 malah kernel: [ 31.555402] ? __warn+0x8d/0x160
Aug 26 00:45:43 malah kernel: [ 31.555406] ? usb_submit_urb+0x64b/0x700
Aug 26 00:45:43 malah kernel: [ 31.555410] ? report_bug+0x1bb/0x1d0
Aug 26 00:45:43 malah kernel: [ 31.555415] ? handle_bug+0x46/0x90
Aug 26 00:45:43 malah kernel: [ 31.555420] ? exc_invalid_op+0x19/0x80
Aug 26 00:45:43 malah kernel: [ 31.555424] ? asm_exc_invalid_op+0x1b/0x20
Aug 26 00:45:43 malah kernel: [ 31.555431] ? usb_submit_urb+0x64b/0x700
Aug 26 00:45:43 malah kernel: [ 31.555435] ? usb_submit_urb+0x64b/0x700
Aug 26 00:45:43 malah kernel: [ 31.555440] usb_start_wait_urb+0x71/0x190
Aug 26 00:45:43 malah kernel: [ 31.555445] usb_control_msg+0xe3/0x160
Aug 26 00:45:43 malah kernel: [ 31.555452] snd_usb_ctl_msg+0xb5/0x190 [snd_usb_audio]
Aug 26 00:45:43 malah kernel: [ 31.555471] snd_sc1810c_get_status_field.constprop.0+0xbe/0x1b0 [snd_usb_audio]
Aug 26 00:45:43 malah kernel: [ 31.555500] snd_s1810c_switch_get+0x86/0x110 [snd_usb_audio]
Aug 26 00:45:43 malah kernel: [ 31.555515] snd_ctl_elem_read+0xef/0x160 [snd]
Aug 26 00:45:43 malah kernel: [ 31.555526] snd_ctl_ioctl+0x527/0x7f0 [snd]
Aug 26 00:45:43 malah kernel: [ 31.555536] ? __x86_return_thunk+0x5/0x10
Aug 26 00:45:43 malah kernel: [ 31.555540] ? __fget_light+0xb5/0x160
Aug 26 00:45:43 malah kernel: [ 31.555546] __x64_sys_ioctl+0x9d/0xe0
Aug 26 00:45:43 malah kernel: [ 31.555552] do_syscall_64+0x5c/0x90
Aug 26 00:45:43 malah kernel: [ 31.555555] ? do_syscall_64+0x69/0x90
Aug 26 00:45:43 malah kernel: [ 31.555558] entry_SYSCALL_64_after_hwframe+0x77/0xe1
Aug 26 00:45:43 malah kernel: [ 31.555562] RIP: 0033:0x7f9d2771aaff
Aug 26 00:45:43 malah kernel: [ 31.555584] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
Aug 26 00:45:43 malah kernel: [ 31.555586] RSP: 002b:00007ffe0f815640 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
Aug 26 00:45:43 malah kernel: [ 31.555589] RAX: ffffffffffffffda RBX: 00005618fe3d6aa0 RCX: 00007f9d2771aaff
Aug 26 00:45:43 malah kernel: [ 31.555591] RDX: 00007ffe0f8156b0 RSI: 00000000c4c85512 RDI: 0000000000000009
Aug 26 00:45:43 malah kernel: [ 31.555593] RBP: 00005618fe3d6aa0 R08: 0000000000000000 R09: 0000000000000000
Aug 26 00:45:43 malah kernel: [ 31.555594] R10: 0000000000000000 R11: 0000000000000246 R12: 00005618fe3d6ac8
Aug 26 00:45:43 malah kernel: [ 31.555596] R13: 00007ffe0f8156b0 R14: 00005618fe3d6e40 R15: 00005618fe3e79fa
Aug 26 00:45:43 malah kernel: [ 31.555602] </TASK>
Aug 26 00:45:43 malah kernel: [ 31.555603] ---[ end trace 0000000000000000 ]---
Outside of tolerance, I would say 
Maybe I shall get a 1810c so that I have both models and can verify that the USB interface is different. There are no complains about 1810c Linux support, the newer model shall work. Default setting is better than with the Windows driver, because the mixer is disabled/bypassed (and unsupported). On Windows, I wanted to use a virtual instrument (VST) and heard the stage piano at the same time because of the mixer, which I had to figure out as a newbie to this interface. It is said that the newer USB-C variant still uses USB 2.0 bus protocol, but obviously with updated firmware and driver. The original driver author used usbmon on Windows for reverse engineering. As far as I know, it is part of Wireshark. I will see what I can do.
7. Alternative: Using virtual machine
Another approach would be a Linux guest system as a virtual machine, with USB port passthrough, similar to PCIe passthrough for the graphics card. A minimal Linux distribution would be sufficient for this approach, the smaller the better. No X/Wayland/Gnome/KDE.
For production audio systems, it is not recommended to use a virtual machine, but this system is just for functional testing.
8. Epilog
I apologize for the lengthy comment, but it may help someone else to keep going and contribute in one way or the other.
Hi all. I wonder if there is a comprehensive guide for kernel module compilation for newer Ubuntu releases (Right now using Xubuntu 22.04, with kernel 6.2.0-32) Currently I am trying to make a small change in the âoptionâ module to support a new GSM modem device. I am able to compile it successfully but it doesnât load properly, complaining with the following errors :
kernel: option: disagrees about version of symbol usb_wwan_write
kernel: option: Unknown symbol usb_wwan_write (err -22)
kernel: option: disagrees about version of symbol usb_wwan_suspend
âŚ
(and a dozen more)
I used the âstandardâ steps as below, (compiling only the usb/serial modules) :
apt-get source linux-image-unsigned-$(uname -r)
cd linux-image*
cp /usr/src/linux-headers-$(uname -r)/Module.symvers .
cp /lib/modules/6.2.0-32-generic/build/.config .config
make modules_prepare
make scripts
make M=drivers/usb/serial
Then copied the file into /lib/modules to replace the original file (old file renamed as option.ko.old). Then tried to load using modprobe, which results in the error above.
I tried to compare the modversions of the original option.ko file with the new one that I compiled from source, without any modifications, and what I am getting is below (the module_layout are same but the other symbols are of different values?)
~$ modprobe --dump-modversions /lib/modules/6.2.0-32-generic/kernel/drivers/usb/serial
/option.ko.old
0x6ebe366f ktime_get_mono_fast_ns
0x2e6c9f5a usb_submit_urb
0x4822a91b __dynamic_dev_dbg
0xb453a97a tty_port_tty_hangup
0x037a0cba kfree
0x2fe55ac8 usb_serial_deregister_drivers
0xad6d045f kmalloc_caches
0x850e6a88 kmalloc_trace
0x3095c58e usb_wwan_port_probe
0xad4650d9 usb_wwan_port_remove
0xbfb095ea usb_wwan_suspend
0xfcff9f67 usb_wwan_resume
0x7165cac2 usb_wwan_open
0xc7dc140d usb_wwan_close
0x00a21b70 usb_wwan_write
0xe2c14860 usb_wwan_write_room
0x88b2ad5e usb_wwan_chars_in_buffer
0xc614ce88 usb_wwan_tiocmget
0x2f107e50 usb_wwan_tiocmset
0xb45bd0d5 usb_wwan_dtr_rts
0xbdfb6dbb fentry
0x5b8239ca __x86_return_thunk
0x60e09f00 usb_serial_register_drivers
0x0453e7dc module_layout
~$ modprobe --dump-modversions /lib/modules/6.2.0-32-generic/kernel/drivers/usb/serial
/option.ko
0x6ebe366f ktime_get_mono_fast_ns
0x2e6c9f5a usb_submit_urb
0x4822a91b __dynamic_dev_dbg
0xb453a97a tty_port_tty_hangup
0x037a0cba kfree
0x15ed2afe usb_serial_deregister_drivers
0xad6d045f kmalloc_caches
0x850e6a88 kmalloc_trace
0x14e60e1d usb_wwan_port_probe
0x07f51ba3 usb_wwan_port_remove
0xd8a4a3a0 usb_wwan_suspend
0xc1b70502 usb_wwan_resume
0xeaedd91f usb_wwan_open
0x5fa04cff usb_wwan_close
0x8068e116 usb_wwan_write
0xf5281be8 usb_wwan_write_room
0xe697d48d usb_wwan_chars_in_buffer
0x932ffb1c usb_wwan_tiocmget
0xc1db490c usb_wwan_tiocmset
0x679191a6 usb_wwan_dtr_rts
0xbdfb6dbb fentry
0x5b8239ca __x86_return_thunk
0xaf254afe usb_serial_register_drivers
0x0453e7dc module_layout
In addition, the file sizes are quite different, the one that I compiled is about 5x the size of the original one installed in the system. I am wondering if the ubuntu-supplied (running) kernel config is really matching the one being distributed in the deb packages.
I have tried to git clone the ubuntu kernel source but still getting the same result. 
In the past I had did the similar steps with older ubuntu versions and also on Debian running on ARM CPU with cross-compile but was able to make it work. Is there anything changed with Jammy?
Apologies if I am posting in the wrong place.
Are you using jammy linux-hwe-6.2, or lunar linux of version 6.2? For example what is the full debian/changelog version number in the top line after calling fakeroot debian/rules clean.
In general, using matching release for the matching kernel build should produce matching results (when stripped of debug symbols!). And normally builds will be the same in a chroot.
You can first try to use mk-sbuild jammy or mk-sbuild lunar and then use sbuild -A -d jammy *.dsc or sbuild -A -d lunar *.dsc as the correct starting point. Note that linux-hwe-6.2 should be built in a jammy chroot. and linux of version v6.2 should be built in lunar chroot. And note that correct toolchains should be used as well. In general it should produce similar results to an existing build.
1 Like
@ombatar this is quite out of scope for this thread in Ubuntu discourse and it is borderline closer to kernel hacking, development and discussions. And there is a forum for that! https://kernelnewbies.org/ maintain multiple mailing lists and IRC channels in addition to wiki page resources dedicated to information, skills and howto guides like yours. Also, most of the lkml hosted mailing lists for different subscections of kernel also accept discussing processes, tools, and specific devices, device drivers and issues with them. They are not limited to patches only! I believe you will find there more people to discuss your ongoing work. Good luck!
Since I am building the kernel module in the same system running the Jammy itself, I assume the apt source will get the Jammyâs linux-hwe-6.2 : linux-hwe-6.2-6.2.0
And for the git clone I checkout the following tag: HEAD is now at e0493668e86f UBUNTU: Ubuntu-hwe-6.2-6.2.0-32.32~22.04.1
And for the output of fakeroot debian/rules clean, I believe this is the line you are looking for: ârm -rf debian.hwe-6.2/abi/6.2.0-32.32~22.04.1â
Good point about the toolchain. Probably the gcc version was different. Is there a proper way to install the correct version of the toolchain to be same as the one used by Ubuntuâs own build system?
Where can I obtain the documentation about the âmk-sbuildâ command and the related build steps that you suggested?
Let me try the mk-sbuild command for now. Thanks a lot.
Hello all, I am still new to the kernel stuff and I have a question. I have ubuntu 18.04 and AX211 adapter. Unfortunetly it doesnt work on 18.04. I discovered that it is because of the 5.4 kernel version. So, I have updated it to 5.15.0-051500-generic using mainline and I am facing some problem.
When I make the package of backport-iwlwifi, I get the following error:
Can anyone guide me throught it? I tried to use " sudo apt install linux-headers-$(uname -r)" and it gives me âE: Package âlinux-headers-5.15.0-051500-genericâ has no installation candidateâ
Really appreciate any help!
Thanks a lot to your advice, after hours of build, I am able to produce the option.ko with exact same modversions of the external symbols! Painfully slow, though, I have to rerun the build after making the patches and realized that it build everything from scratch againâŚ
However, my question remains, what are the differences between compiling using the standard make M=xxx command vs using the sbuild, that could cause the differences in the modversions (other than the kernel version and .config) ?
It assembles config from annotations, sets kernel version, package version, correct compiler version (i.e. gcc-12 for some hwe backports in jammy), and lots of other variables to the kmake invocation.
If you are iterating locally you can keep the build tree, and build the kernel modules the exactly the same way as the full build process does it by invoke things via the debian/rules entry point.
I typically create a schroot session (with schroot --begin-session) for the correct target release. Install all the declared build dependencies with (fakeroot debian/rules clean; apt install build-dep ./) and then can invoke single flavour build with DEB_BUILD_OPTIONS=parallel=16 ./debian/rules build-generic tweaking the build tree i can recompile changes by re-invoking that.
One can keep the build source inside the schroot session, or change /etc/schroot config to bind-mount your /home directory into the shcroot sessions as rw => this allows me to keep all the source code & build objects on my host system, and only have all the compilers and build-dependencies in a clean chroot which mimicks the same build envrionment as the full sbuild calls as used in production builds.
In later releases such as 20.04 we provide both HWE v5.15 kernel with stock iwlwifi, but also we provide the optional backport-iwlwifi driver already precompiled and signedâŚ
⌠meaning if you can upgrade to 20.04 you can just install hwe kernel & backports-iwlwifi stack as packages without needing to compile anything.
If you canât upgrade from 18.04, you could maybe pin down focal-updates release and only selectively install linux-generic-hwe-20.04 linux-modules-iwlwifi-generic-hwe-20.04 which will give you v5.15 kernel and AX211 support.
have updated it to 5.15.0-051500-generic using mainline
I donât know where you got that build and how, but it should contain headers package next to the image and modules, which should be possible for you to install to have matching headers for the matching prebuilt kernel you fetched.
But I would rather recommend you to upgrade to any newer releases which have AX211 support out of the box provided by the Ubuntu Kernel team.
3 Likes
Thanks for your reply. Can you please guide me through how to pin down the focus release or if you know a good tutorial for that?
I have tried some things and unfortunately one of them did something wrong with my kernel and windows stopped opening.
Does this solution need to update the 5.4 Ubuntu 18.04 kernel ?
I need Ubuntu 18.04 specifically as Iâm using ROS melodic with it.
Thanks for your time.
I have tried this tutorial where I have installed kernel 5.15.0-83-generic: https://ubuntuhandbook.org/index.php/2022/03/install-kernel-5-13-ubuntu-18-04/
I have also tried to install the Intel AX211 firmware using the first answer here: https://askubuntu.com/questions/1368240/running-intel-wi-fi-6-ax210-adapter-under-ubuntu-18-04
It worked but I get this warning:
Although it worked, but I cannot enter the Ubuntu with kernel 5.15 the normal way, only entering recovering mode working no idea why.