Ask us anything about Ubuntu Kernels!

Canonical has a business to run. If their business does not need a new kernel built for their testing then no one has the time or resources to fix any breakage with the automated mainline kernel builds.

Until Canonical chooses which new Linux kernel to use for Lunar Lobster testing it is unlikely for these mainline kernel builds to be fixed. I suspect Canonical will pick 6.1 as it is an LTS kernel but the Lunar release is not an Ubuntu LTS so who knows ?

Anyway Feature Freeze is the end of February, so for sure it will be fixed by sometime in February.
Also Ubuntu Testing week is in March.
See Lunar Lobster Release Schedule

I want to specify the kernel version to 5.4.0-125, but the code i use in user-data doesn’t work . When install the OS , it will always update to 5.4.0-150.
kernel:
package: linux-image-5.4.0-125-generic

How do you install the OS? Is this cloud-init user-data? If so, can you post your cloud-init config?

Yes, I use the cloud-init user-data to install os automatically.
My config file :
autoinstall:
version: 1
refresh-installer:
update: no
#Network configuration for DHCP
network:
network:
version: 2
ethernets:
any:
match:
name: eno*
dhcp4: true

Identity and HostName

identity:
hostname: localhost-sut
username: ubuntu
password: “*”
ssh:
allow-pw: true
authorized-keys: []
install-server: true

Timezone setting

timezone: ‘Asia/Shanghai’

APT setup

apt:
primary:
- arches:
- default
uri: http://100.109.32.49/ipxe/os/ubuntu/20.04.5/
kernel:
package: linux-image-5.4.0-125-generic
keyboard:
layout: us
toggle: null
variant: ‘’
locale: en_US.UTF-8
source:
id: ubuntu-server
search_drivers: false
storage:
layout:
name: lvm
updates: security

please add three backticks ``` in the line before and after any code you paste, so the indentation stays intact else your paste will be unreadable …

Hi, this is not really a kernel question, but a question about Subiquity installer, autoinstall option. It’s best to ask about it at Please test autoinstalls for 20.04! - #32 by mwhudson

In general, Ubuntu updates are rolling, meaning your kernel just like all the other packages will be upgraded. 5.4.0-125 is a very old kernel build which is no longer supported. It is not recommended to install individual kernel ABI packages, and instead you should only install the meta that will keep your systems updated (as is done by default).

Why are you trying to install an obsolete and security vulnerable build of v5.4 kernel, when latest abi is 150?

2 Likes

Yes, it is a question for installer . But i am not sure why it will always be upgraded to the newest .

My customer required to use the stable kernel version ,so i need to hold the kernel the special verison.

I have find the solution and thank you for your clarify and advise .Thank you

Did you make your customer at least aware that you are installing something with well known and documented vulnerabilities so that hackers even have a tutorial how to break in ? You seem to be doing your customer quite a disservice here if you do not try to convince them to use a kernel with the fixes…

2 Likes

On my Dell inspiron I have a problem wit kernel 6.x: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015670
and I am forced to use a 5.x kernel
may you help me?
thanks

Hm. Looks familiar to something I’m seeing with a Realtek NIC but with kernel 5.19. Can you try to add kernel commandline pcie_aspm=off.

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 1

Can 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 :slight_smile: 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 :frowning_face:

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.