Dear Maintainer,

as of a couple of months ago I have regular issues with the USB C to audio jack module from Framework, and any error logs of the time this happens point to the Kernel. E.g. I compiled 6.13.4 from source, based on the config Debian shipped with the 6.12.15 Kernel (updated with make olddefconfig), there it shows these messages:

Mär 01 17:31:43 kernel: usb 1-2.2: 1:1: cannot set freq 48000 (v2/v3): err -110
Mär 01 17:31:48 kernel: usb 1-2.2: uac_clock_source_is_valid(): cannot get clock validity for id 9
Mär 01 17:31:48 kernel: usb 1-2.2: clock source 9 is not valid, cannot use
Mär 01 17:31:53 kernel: usb 1-2.2: 1:1: cannot get freq (v2/v3): err -110


These issues started at some point late last years, possibly since 6.12 was introduced into testing. I've tested up until 6.13.6 now, with no change, only a varying degree of information in the logs. A detailed thread can be found in [1]. What should be mentioned, originally, when this happened, all audio devices would vanish from Gnome settings audio page. But with 6.13, they still all show up, but e.g. if you open the little audio channel test widget and try to test a channel, the widget just freezes up.


Framework themselves can't to further debugging, as they only officially support Ubuntu and Fedora. Running any of them as a live distro is simply not feasible, as this issue can't just be triggered and only appears about once a week.


Is there something else to help finding out, where the issue is located, or even rule out a software issue? I'm already testing out the other USB C ports of my Framework 16, but the point is that I don't have any other device capable of USB C and using that audio module.


[1]: https://community.frame.work/t/responded-audio-expansion-card-connection-sometimes-unreliable/62951/20

Something I just noticed, while Firefox refuses to play back any media
when this happens, mpv does, but playback seems a bit distorted, and
these messages now appear in the user logs:


Mär 24 18:59:29 pipewire[2927]: spa.alsa: set_hw_params: Connection timed out
Mär 24 18:59:29 pipewire[2927]: pw.node:
(alsa_output.usb-Framework_Audio_Expansion_Card-00.analog-stereo-71)
suspended -> error (Start error: Connection timed out)
Mär 24 18:59:29 wireplumber[2934]: wp-event-dispatcher:
<WpAsyncEventHook:0x55fad05c03d0> failed:
<WpSiStandardLink:0x55fad09f9100> link failed: item deactivated before
format was set
Mär 24 18:59:54 pipewire[2927]: spa.alsa: set_hw_params: Connection timed out
Mär 24 18:59:54 pipewire[2927]: pw.node:
(alsa_output.usb-Framework_Audio_Expansion_Card-00.analog-stereo-71)
suspended -> error ((null))
Mär 24 18:59:54 pipewire[2927]: pw.link: 0x559101476130: one of the
nodes is in error out:idle in:error
Mär 24 18:59:54 pipewire[2927]: pw.link: 0x559101360b60: one of the
nodes is in error out:idle in:error
Mär 24 18:59:56 mpv[10872]: pw.conf: setting config.name to
client-rt.conf is deprecated, using client.conf
Mär 24 18:59:56 xdg-desktop-por[3882]: Realtime error: Could not get
pidns: Could not fstatat ns/pid: Not a directory
Mär 24 18:59:56 gnome-shell[3248]:
meta_window_set_stack_position_no_sync: assertion
'window->stack_position >= 0' failed
Mär 24 18:59:56 pipewire[2927]: pw.link: 0x55910157f5b0: one of the
nodes is in error out:suspended in:error
Mär 24 18:59:56 pipewire[2927]: pw.link: 0x55910157d590: one of the
nodes is in error out:suspended in:error
Mär 24 19:00:28 pipewire[2927]: spa.alsa: set_hw_params: Connection timed out
Mär 24 19:00:28 pipewire[2927]: pw.node:
(alsa_output.usb-Framework_Audio_Expansion_Card-00.analog-stereo-71)
suspended -> error (Start error: Connection timed out)


and playback in Firefox seems to be broken due to these messages:

Mär 24 18:54:47 pipewire[2927]: spa.alsa: set_hw_params: Connection timed out
Mär 24 18:54:47 pipewire[2927]: pw.node:
(alsa_output.usb-Framework_Audio_Expansion_Card-00.analog-stereo-71)
suspended -> error (Start error: Connection timed out)
Mär 24 18:54:51 firefox-beta.desktop[7437]: [Child 7437,
MediaDecoderStateMachine #4] WARNING: 7f33ca3b73a0 OpenCubeb() failed
to init cubeb: file
/builds/worker/checkouts/gecko/dom/media/AudioStream.cpp:284
Mär 24 18:54:51 firefox-beta.desktop[7437]: [Child 7437,
MediaDecoderStateMachine #4] WARNING: Decoder=7f33d511a700
[OnMediaSinkAudioError]: file
/builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:4633


During these time stamps, the Kernel keeps spamming

Mär 24 18:59:44 kernel: usb 5-1: clock source 9 is not valid, cannot use
Mär 24 18:59:49 kernel: usb 5-1: 1:3: cannot get freq (v2/v3): err -110
Mär 24 18:59:54 kernel: usb 5-1: 1:3: cannot set freq 48000 (v2/v3): err -110
Mär 24 19:00:07 kernel: usb 5-1: 1:0: usb_set_interface failed (-110)
Mär 24 19:00:12 kernel: usb 5-1: 1:0: usb_set_interface failed (-110)
Mär 24 19:00:18 kernel: usb 5-1: uac_clock_source_is_valid(): cannot
get clock validity for id 9
Mär 24 19:00:18 kernel: usb 5-1: clock source 9 is not valid, cannot use
Mär 24 19:00:23 kernel: usb 5-1: 1:3: cannot get freq (v2/v3): err -110


(during both user space errors). So something on a low level seems
off. This occured on Kernel 6.14.

Hello Richard,

I guess the problem is that the USB messages that the USB clock driver
(sound/usb/clock.c) is sending don't get a reply in time. (-110 =
ETIMEDOUT).

Do I understand correctly that audio usually works, just about once per
week the above mentioned lines are found in the kernel log and then it
doesn't work?

Do these messages happen during boot? Or when you start using audio?
Does a reboot help then? Or replugging the audio hardware (or is this an
internal USB-C device)?

Does the bookworm kernel work on this machine? You could try that then.
Or the Ubuntu kernel might be worth a try.

Best regards
Uwe

Hi Uwe,


Good call, I'll forward that to Framework when I talk to them the next time


Exactly. Recently it's usually between Fridays and Mondays where it will just randomly not work.
It's usually when I plug in my headphone cable. Sometimes that's the first time on that boot or sometimes it worked before. Then no audio device will work at all. Also, in the Gnome system settings, either all audio devices vanish or they are still there, but if I e.g. open that channel test applet and try to play audio through either channel, nothing plays and it seems the applet freezes.


Something I recently  noticed, while Firefox refuses to play back any media when this happens, mpv does, but playback seems a bit distorted, and these messages now appear in the user logs:

Mär 24 18:59:29 pipewire[2927]: spa.alsa: set_hw_params: Connection timed out
Mär 24 18:59:29 pipewire[2927]: pw.node: (alsa_output.usb-Framework_Audio_Expansion_Card-00.analog-stereo-71) suspended -> error (Start error: Connection timed out)
Mär 24 18:59:29 wireplumber[2934]: wp-event-dispatcher: WpAsyncEventHook:0x55fad05c03d0 failed: WpSiStandardLink:0x55fad09f9100 link failed: item deactivated before format was set
Mär 24 18:59:54 pipewire[2927]: spa.alsa: set_hw_params: Connection timed out Mär 24 18:59:54 pipewire[2927]: pw.node: (alsa_output.usb-Framework_Audio_Expansion_Card-00.analog-stereo-71) suspended -> error ((null))
Mär 24 18:59:54 pipewire[2927]: pw.link: 0x559101476130: one of the nodes is in error out:idle in:error
Mär 24 18:59:54 pipewire[2927]: pw.link: 0x559101360b60: one of the nodes is in error out:idle in:error
Mär 24 18:59:56 mpv[10872]: pw.conf: setting config.name to client-rt.conf is deprecated, using client.conf
Mär 24 18:59:56 xdg-desktop-por[3882]: Realtime error: Could not get pidns: Could not fstatat ns/pid: Not a directory
Mär 24 18:59:56 gnome-shell[3248]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Mär 24 18:59:56 pipewire[2927]: pw.link: 0x55910157f5b0: one of the nodes is in error out:suspended in:error
Mär 24 18:59:56 pipewire[2927]: pw.link: 0x55910157d590: one of the nodes is in error out:suspended in:error
Mär 24 19:00:28 pipewire[2927]: spa.alsa: set_hw_params: Connection timed out
Mär 24 19:00:28 pipewire[2927]: pw.node: (alsa_output.usb-Framework_Audio_Expansion_Card-00.analog-stereo-71) suspended -> error (Start error: Connection timed out)


and playback in Firefox seems to be broken due to these messages:

Mär 24 18:54:47 pipewire[2927]: spa.alsa: set_hw_params: Connection timed out
Mär 24 18:54:47 pipewire[2927]: pw.node: (alsa_output.usb-Framework_Audio_Expansion_Card-00.analog-stereo-71) suspended -> error (Start error: Connection timed out)
Mär 24 18:54:51 firefox-beta.desktop[7437]: [Child 7437,MediaDecoderStateMachine #4] WARNING: 7f33ca3b73a0 OpenCubeb() failed to init cubeb: file /builds/worker/checkouts/gecko/dom/media/AudioStream.cpp:284
Mär 24 18:54:51 firefox-beta.desktop[7437]: [Child 7437, MediaDecoderStateMachine #4] WARNING: Decoder=7f33d511a700 [OnMediaSinkAudioError]: file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:4633


During these time stamps, the Kernel keeps spamming

Mär 24 18:59:44 kernel: usb 5-1: clock source 9 is not valid, cannot use Mär 24 18:59:49 kernel: usb 5-1: 1:3: cannot get freq (v2/v3): err -110 Mär 24 18:59:54 kernel: usb 5-1: 1:3: cannot set freq 48000 (v2/v3): err -110
Mär 24 19:00:07 kernel: usb 5-1: 1:0: usb_set_interface failed (-110)
Mär 24 19:00:12 kernel: usb 5-1: 1:0: usb_set_interface failed (-110)
Mär 24 19:00:18 kernel: usb 5-1: uac_clock_source_is_valid(): cannot get clock validity for id 9
Mär 24 19:00:18 kernel: usb 5-1: clock source 9 is not valid, cannot use
Mär 24 19:00:23 kernel: usb 5-1: 1:3: cannot get freq (v2/v3): err -110


(during both user space errors). So something on a low level seems off.


Only rebooting helps. I'm currently trying not use the headphone jack expansion module, but the normal USB C module and a USB C to jack adapter I had lying around, that way I can test out if this may be an issue with the expansion card. I also had the battery run empty, remove SSD, RAM, battery and all modules a few days ago after that was recommended by Framework support, but the results are still not in.

I would prefer to use a newer Kernel since on one hand features like VRR are missing from 6.1 (also I don't even know how far that would boot, I did install bookworm originally because at that time the Calamares installer was missing from testing ISO, but I think I at least updated Kernel and Firmware to backports/upstream) and bookworm-backports is probably still missing quite a lot of fixes for various amdgpu issues. And since I'm currently on Kernel 6.14, compiled from source based on the config from 6.12.15, I don't know if another Debian Kernel would be enough.


But yes, trying the Kernel from one of the officially supported Ubuntu or Fedora distros was also recommended by the support, so that would be Ubuntu 22.04, 24.04 or Fedora 41. With Ubuntu, can I just install their .deb package? I would still have to ask Framework support which Kernel they recommend, generic seems to be only v6.8 in 24.04, linux-image-generic-hwe-24.04 is v6.11.0, linux-oem-24.04b is another version of 6.11.0. Though, because of newer Kernel version, I had asked them if they happened to know where I could get sources and config for the latest Kernel in Fedora 41, so I could just put that through "make bindeb-get" and install that one. But they haven't come back to me yet with that one. But if you think that could also be worth a try and happen to know where I can get the parts (or can tell me where I can get their rpm and install the Kernel with that manually), I would try that, at least after verifying the current tests.


Best

Richard

Hello Richard,

Maybe it's worth to try to reload the usb bus driver in the broken
state. Something like:

	# cd -P /sys/bus/usb/devices/usb5/../driver/
	# echo 0000:02:00.0 > unbind
	# echo 0000:02:00.0 > bind

(where 0000:02:00.0 is a link in the directory that the first command
cd'd into). Note that

a) there might be several device links in that directory, try

	ls -ld /sys/bus/usb/devices/usb5

   to determine the right one.

b) While I expect that the format of the device string matches mine, it
   might also be something completely different.

c) When unbinding the usb bus driver your USB keyboard might stop
   working. So either do bind and unbind in a single line (and hope that
   binding works again :-), or do that via network (or with a PS/2
   keyboard).

I tried installing an Ubuntu (noble) kernel in a Debian 12 VM. While
this worked and produced a booting system, it pulled in quite some
dependencies, so it might get hard to restore an all-Debian system
afterwards.

Best regards
Uwe

Thanks for the recommendation, I'll try that the next time it happens. For what it's worth, I already tried out 6.14.1, and it seems to have made things a lot worse. I had this issue happen today and yesterday, which never happened before. It was always at least 5-8 days inbetween. So I went back to 6.14.0 for now, as for the next couple of days I'll need a more robust system. But if 6.14.1 ends up making this issue a lot more frequent, at least it's easier to see what works and what doesn't.

Are all these dependencies needed though? Because at least when I compile a .deb package from upstream sources with make bindeb-pkg it doesn't put any dependencies into the package. So if I were to get e.g. this tag [1] from their launchpad, get the config from here [2] and let it compile, wouldn't that also do the trick and combine it all into one package that would be much easier to handle? Grub and initramfs-tools are already there, and I don't see anything else that could be relevant that wouldn't already be in that one package.


Best

Richard


[1]: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/plucky/tag/?h=Ubuntu-6.14.0-15.15

[2]: https://packages.ubuntu.com/plucky/linux-modules-6.14.0-13-generic

Hi Uwe
On 08.04.25 18:56, Uwe Kleine-König wrote:
 > Maybe it's worth to try to reload the usb bus driver in the broken
 > state. Something like:
 >
 >     # cd -P /sys/bus/usb/devices/usb5/../driver/
 >     # echo 0000:02:00.0 > unbind
 >     # echo 0000:02:00.0 > bind
 >
 > (where 0000:02:00.0 is a link in the directory that the first command
 > cd'd into). Note that


That doesn't  seem to be an option. The error messages right now point to "/sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2". cd'ing to "/sys/bus/usb/devices/usb1/1-2/1-2.2/" (or just to "/sys/bus/usb/devices/usb1/" fails, nothing happens.
 >
 >
 > a) there might be several device links in that directory, try
 >
 >     ls -ld /sys/bus/usb/devices/usb5
 >
 >    to determine the right one.

This shows this symlink:


ls -ld /sys/bus/usb/devices/usb1
lrwxrwxrwx 1 root root 0 25. Apr 19:18 /sys/bus/usb/devices/usb1 -> ../../../devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1


With that information I can cd to "/sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2", but then I don't understand what you mean with "where 0000:02:00.0 is a link in the directory that the first command
cd'd into". The only symlinks in the directory I'm inside now are:

driver -> ../../../../../../../bus/usb/drivers/usb

port -> ../1-2:1.0/1-2-port2

subsystem -> ../../../../../../../bus/usb

cd'ing (with or without -P) into driver shows a lot of symlinks.



Anyway, I came to the conclusion with Framework that all this is probably a hardware issue and we hope the issue is fixed with a replacement module. It arrived a couple of days ago and I just left the old one inside to see if I can follow these instructions and if they had any success. I'll be switching to the new module now and hope that this actually fixes things. Fingers crossed. If not I'll be reporting back here in a week or two and maybe we can brainstorm on that issue  a bit more.


Best Regards

Richard

So, it has been a while, here a little update. As I couldn't figure out - and didn't have the time to do so - how to compile Fedora's kernel sources with their config through make bindeb-pkg, I didn't even bother trying with Ubuntu's kernel. I have now used the Fedora 41 live USB for the past two weekends and the most part of the past week, yet the issue didn't show up once. And since I very much doubt that to be a coincidence and the issue just fixed itself, the issue must be located in some place inside what Trixie has been shipping for roughly the last 6 months (I first reported this in early January to the Framework community, but that's just when it became frequent enough and had been around already for at least a month if not more, I'd say.


The only additional information I can provide at this point is logs I gathered with a script the Framework support gave me [1] that I sent them for analysis. But I'm not convinced they'll show anything of importance, as otherwise the FW guys could have already spotted it. But if anyone has any additional ideas on how to figure out the cause, do let me know.


Best

Richard


[1]: https://raw.githubusercontent.com/FrameworkComputer/linux-docs/main/log-helper/combined.sh

Which version of the Fedora kernel are you using? Can you test the base
version, too? (So if Fedora uses a modified 6.13.7, test on a vanilla
6.13.7. That allows to determine if there is something in the Fedora
patch stack that helps or if it's just a different base version that is
improved compared to the 6.12.17 kernel that you reported this issue
against.)

Best regards
Uwe

Hello Richard,

cd isn't supposed to do anything apart from changing the current working
directory. The right numbers in this case seem to be:

	cd /sys/bus/usb/devices/usb1/../driver/
	echo 0000:c1:00.3 > unbind
	echo 0000:c1:00.3 > bind

Before the 2nd command, there should be a symlink
`/sys/bus/usb/devices/usb1/../driver/0000:c1:00.3`. That's what I meant
with my note in parenthesis.

You can test that even without the problem. The first echo should result
in the audio device disappearing, the second should make it reappear. If
these are the effects, then that's the right procedure to try when audio
is broken next time.

Your more recent reply to this bug means that the problem isn't solved?

Best regards
Uwe

For compiling the latest 6.14 version that was in the repos. The thing where I just stopped trying and used the Fedora 41 ISO instead was a signing failure if I remember correnctly. The Kernel Fedora 41 shipps with is 6.11.4-301.


Once the issue happens again (so I see how well 6.15 fares which I currently run), I'll be trying out Fedora 42, which comes with 6.14.0-63, it's entirely possible that the issues only started with 6.12, I can't tell for sure anymore.


Best regards

Richard

Hi Uwe,

I'll try that again once it happens again. But I've already tested it (and ended up in /sys/bus/usb/drivers/usbhid following the symlinks), but echoing to unbind gives me


echo 0000:c1:00.3 > unbind
-bash: echo: write error: No such device


(executed as root). dmesg says about the Audio expansion module:

input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2/1-2.2:1.2/0003:32AC:0010.0009/input/input18
hid-generic 0003:32AC:0010.0009: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2


So even if I go to /sys/bus/usb/devices/usb1/1-2/1-2.2/1-2.2:1.2/driver/, I still get no such device.


Most likely not, or I would be very surprised. It hasn't reappeared since I started the tests, but I shall see in the next couple of days if Kernel 6.15 somehow fixed this. The last Kernel I tried on Debian where the issue appeared was 6.14.5, which made the issue a lot worse, causing it to basically happen on a daily basis.


Best Richard

So, I've used Kernel 6.15.0 since the day it was released until 2 days ago. In all that time the issue didn't happen once. Two days ago I went back to 6.12.32-1 from the repos and it just happened to me just now. So either the fix of the issue was introduced at some point between the release of 6.14.5 and 6.15, as 6.14.5 was the lastest version I used that showed this issue, or at least something was changed that made this issue appear a lot less frequent.


Best regards

Richard

Hello Richard,

It would be great to identify the relevant change that is maybe can be
backported to 6.12.y.

Do I remember correctly that a reboot fixes the issue? If so I'd still
be interested to test reloading drivers without a reboot. Would you be
open for a more interactive debug session via irc?
If yes, but you don't do irc already, the easiest option is probably
using

https://webchat.oftc.net/?channels=debian-kernel

(just pick a nickname, connect and prod me by writing something
containing "ukleinek". With a bit of luck our waketimes intersect enough
(I'm in UTC+2).

Best regards
Uwe

Hi Uwe,

it looks like I've spoken too soon. It just happened again on 6.15.3. I'm back to 6.15.2 again to check if it happens there or if something was reintroduced in 6.15.3 that triggers this.


Jun 24 17:40:17 kernel: SCSI subsystem initialized
Jun 24 17:40:19 kernel: hid-generic 0003:32AC:0003.0009: hiddev0,hidraw2: USB HID v1.11 Device [Framework DisplayPort Expansion Card] on usb-0000:c1:00.3-1/input1
Jun 24 17:40:45 kernel: usbhid 1-2.2:1.2: can't add hid device: -110
Jun 24 17:40:45 kernel: usbhid 1-2.2:1.2: probe with driver usbhid failed with error -110
Jun 24 17:40:56 kernel: usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd
Jun 24 17:40:56 kernel: usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd
Jun 24 17:41:20 kernel: usb 1-2.2: USB disconnect, device number 9
Jun 24 17:41:25 kernel: usb 1-2.2: new high-speed USB device number 10 using xhci_hcd
Jun 24 17:41:25 kernel: usb 1-2.2: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
Jun 24 17:41:25 kernel: usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 24 17:41:25 kernel: usb 1-2.2: Product: Audio Expansion Card
Jun 24 17:41:25 kernel: usb 1-2.2: Manufacturer: Framework
Jun 24 17:41:25 kernel: input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2/1-2.2:1.2/0003:32AC:0010.000A/input/input19
Jun 24 17:41:25 kernel: hid-generic 0003:32AC:0010.000A: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2
Jun 24 17:41:30 kernel: usb 1-2.2: uac_clock_source_is_valid(): cannot get clock validity for id 9
Jun 24 17:41:30 kernel: usb 1-2.2: clock source 9 is not valid, cannot use
Jun 24 17:41:35 kernel: usb 1-2.2: 1:1: cannot get freq (v2/v3): err -110
Jun 24 17:41:40 kernel: usb 1-2.2: 1:1: cannot set freq 48000 (v2/v3): err -110
Jun 24 17:41:46 kernel: usb 1-2.2: uac_clock_source_is_valid(): cannot get clock validity for id 9
Jun 24 17:41:46 kernel: usb 1-2.2: clock source 9 is not valid, cannot use
Jun 24 17:41:51 kernel: usb 1-2.2: 1:1: cannot get freq (v2/v3): err -110
Jun 24 17:41:51 kernel: usbhid 1-2.2:1.2: can't add hid device: -110
Jun 24 17:41:51 kernel: usbhid 1-2.2:1.2: probe with driver usbhid failed with error -110
Jun 24 17:41:56 kernel: usb 1-2.2: 1:1: cannot set freq 48000 (v2/v3): err -110
Jun 24 17:42:01 kernel: usb 1-2.2: uac_clock_source_is_valid(): cannot get clock validity for id 9
Jun 24 17:42:01 kernel: usb 1-2.2: clock source 9 is not valid, cannot use
Jun 24 17:42:06 kernel: usb 1-2.2: 1:1: cannot get freq (v2/v3): err -110
Jun 24 17:42:11 kernel: usb 1-2.2: 1:1: cannot set freq 48000 (v2/v3): err -110
Jun 24 17:42:16 kernel: usb 1-2.2: uac_clock_source_is_valid(): cannot get clock validity for id 9
Jun 24 17:42:16 kernel: usb 1-2.2: clock source 9 is not valid, cannot use
Jun 24 17:42:21 kernel: usb 1-2.2: 1:1: cannot get freq (v2/v3): err -110
Jun 24 17:42:27 kernel: usb 1-2.2: 1:1: cannot set freq 48000 (v2/v3): err -110


This time around though, not the whole audio systems seems to crash. Audio output via speakers is still available.


Sadly, rebinding the driver doesn't seem to be an option still. Upon plugging in headphones to the audio expansion card, I see a new device under /sys/class/sound:


card2 -> ../../devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2/1-2.2:1.0/sound/card2


So technically I should be able to do


cd -P /sys/class/sound/card2/device/driver

echo 0000:c1:00.3 > unbind


but that only gives me

Hello Richard,

	echo 1-2.2:1.0 > unbind

instead. As long as the device is bound, there is a symlink in the
driver dir with the device that you can echo into unbind.

As example from my machine: I have /sys/class/sound/card0 pointing to
../../devices/pci0000:00/0000:00:1f.3/sound/card0.

uwe@taurus:~$ cd -P /sys/class/sound/card0/device/driver

uwe@taurus:/sys/bus/pci/drivers/snd_hda_intel$ ls
0000:00:1f.3  bind  module  new_id  remove_id  uevent  unbind

So I could do:

	echo 0000:00:1f.3 > /sys/bus/pci/drivers/snd_hda_intel/unbind
	echo 0000:00:1f.3 > /sys/bus/pci/drivers/snd_hda_intel/bind

.

from the data you provided I would expect that you can do that with:

	cd -P /sys/devices/pci0000:00/0000:00:08.1/driver
	echo 0000:00:08.1 > unbind
	echo 0000:00:08.1 > bind

Best regards
Uwe

HI Uwe,
So the good news is, unbinding 1-2.2:1.0 does remove the module, but binding it again doesn't activate it again. Not even unplugging the module and plugging it back in results in it showing up again. Not in Gnome settings, not in lsusb. That's what logs have to say about the process:


Jun 26 18:54:09 kernel: usb 1-2.2: USB disconnect, device number 11
Jun 26 18:54:13 kernel: usb 1-2.2: new high-speed USB device number 12 using xhci_hcd
Jun 26 18:54:13 kernel: usb 1-2.2: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
Jun 26 18:54:13 kernel: usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 26 18:54:13 kernel: usb 1-2.2: Product: Audio Expansion Card
Jun 26 18:54:13 kernel: usb 1-2.2: Manufacturer: Framework
Jun 26 18:54:13 kernel: input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2/1-2.2:1.2/0003:32AC:0010.000F/input/input24
Jun 26 18:54:13 kernel: hid-generic 0003:32AC:0010.000F: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2
Jun 26 18:54:14 kernel: input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2/1-2.2:1.2/0003:32AC:0010.0010/input/input25
Jun 26 18:54:14 kernel: hid-generic 0003:32AC:0010.0010: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2

(sent unbind at roughl 18:53:28, with bind following just a couple moments later. Yet there are no other entries by the Kernel from between that time stamp and 18:54:09. In the /sys/bus/usb/drivers/snd-usb-audio directory is also, 1-2.2:1.1, but I can only unbind it but not bind it. But that just seems to be the DP module, as removing it also removes the entry.
That one actually looks like it's not really doing anything. Even with that device unbound, audio still works through the module. And yes, it's still showing in Kernel logs to be located at "/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2/1-2.2:1.2/0003:32AC:0010.0004/input/input7". It doesn't even change the number of entries of lspci. Though unbinding seems to be successful, as unbinding again before bind results in "no such device". Only logs entries for that (unbind and then bind) being


Jun 26 19:13:11 framework16 kernel: pcieport 0000:00:08.1: PME: Signaling with IRQ 42
Jun 26 19:13:11 framework16 boltd[1359]: probing: started [1000]
Jun 26 19:13:13 framework16 boltd[1359]: probing: timeout, done: [2002817] (2000000)


I'll be testing 6.15.2 at least for another two weeks to see if that's also affected. If we find a solution to successfully unbind and bind the device, I'll give 6.15.3 another shot and see if that helps when the issue appears.


Best regards

Richard

Hello Richard,

I don't know about the details of usb. I would compare the messages to
the ones that are emitted when you plug in the audio stick the first
time.

The device seems to still provide 1-2.2:$something, so that part isn't
surprising. Maybe there is still something left of the binding that
prevents a proper reinitialisation.

That sounds like a bug to forward to upstream and/or framework.

After bind it's expected that
/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2/... works
again. Does this cure the problem that you have after unbinding
1-2.2:1.1?

Best regards
Uwe

Hi Uwe,

That's literally it. Booting up with headphones plugged in creates these two lines in dmesg:


[  +0.000977] [Wed Jul  2 21:40:15 2025] input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2/1-2.2:1.2/0003:32AC:0010.0004/input/input7
[  +0.052490] [Wed Jul  2 21:40:15 2025] hid-generic 0003:32AC:0010.0004: input,hidraw3: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2


The only thing that does seem to change between boots is "0003:32AC:0010.0004", though that may be because I usually don't change the place I plug the module in.
So, maybe let me clear things up a bit more: in your last message you said

from the data you provided I would expect that you can do that with:


cd -P /sys/devices/pci0000:00/0000:00:08.1/driver
echo 0000:00:08.1 > unbind
echo 0000:00:08.1 > bind


this wouldn't work for me. To unbind the module, I need to do


cd -P /sys/class/sound/card0/device/driver
echo 1-2.2:1.0 > unbind


Following that with a echo 1-2.2:1.0 > bind doesn't bring the device back up. Kernel logs look like it, but it doesn't show up again in Gnome settings.


Jul 02 22:22:44 boltd[1351]: probing: started [1000]
Jul 02 22:22:44 systemd[6068]: Reached target sound.target - Sound Card.
Jul 02 22:22:47 boltd[1351]: probing: timeout, done: [2997515] (2000000)
Jul 02 22:22:50 kernel: usb 1-2.2: USB disconnect, device number 10
Jul 02 22:22:50 keyd[1143]: DEVICE: removed 32ac:0010:00c7003e Framework Audio Expansion Card Consumer Control
Jul 02 22:22:55 kernel: usb 1-2.2: new high-speed USB device number 11 using xhci_hcd
Jul 02 22:22:55 kernel: usb 1-2.2: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
Jul 02 22:22:55 kernel: usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 02 22:22:55 kernel: usb 1-2.2: Product: Audio Expansion Card
Jul 02 22:22:55 kernel: usb 1-2.2: Manufacturer: Framework
Jul 02 22:22:55 kernel: input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2/1-2.2:1.2/0003:32AC:0010.000D/input/input22
Jul 02 22:22:55 keyd[1143]: DEVICE: match    32ac:0010:00c7003e /etc/keyd/default.conf        (Framework Audio Expansion Card Consumer Control)
Jul 02 22:22:55 kernel: hid-generic 0003:32AC:0010.000D: input,hidraw3: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2
Jul 02 22:22:55 mtp-probe[6819]: checking bus 1, device 11: "/sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2"
Jul 02 22:22:55 mtp-probe[6819]: bus: 1, device: 11 was not an MTP device
Jul 02 22:22:55 boltd[1351]: probing: started [1000]
Jul 02 22:22:55 keyd[1143]: DEVICE: removed 32ac:0010:00c7003e Framework Audio Expansion Card Consumer Control
Jul 02 22:22:56 kernel: input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2/1-2.2:1.2/0003:32AC:0010.000E/input/input23
Jul 02 22:22:56 fwupd[4698]: 20:22:56.114 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2: failed to setup: failed to get firmware version info: unknown error -22
Jul 02 22:22:56 kernel: hid-generic 0003:32AC:0010.000E: input,hidraw3: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2
Jul 02 22:22:58 boltd[1351]: probing: timeout, done: [2732716] (2000000)


unbinding and binding does cause the device to disappear and reappear as card0 in /sys/class/sound/, but nothing more as far as I can tell. No idea if there's another place that could show the presence of the module. And no, unplugging it and plugging it back in also doesn't have it reappear, only a reboot seems to help. Though I was able to translate the unbinding you suggested to my system. For me it has to look like this:


cd -P /sys/devices/pci0000\:00/0000\:00\:08.1/0000\:c1\:00.3/driver
echo 0000:c1:00.3 > unbind
echo 0000:c1:00.3 > bind


This in fact does seem to remove something higher up the chain, as it kills both keyboard and fingerprint sensor, which are both on bus 1, only keeping the touchpad operational, which doesn't seem to show up as a dedicated device on either lsusb or lspci. But even rebinding that driver doesn't allow for the audio module to come back up fully.


Best regards

Richard

Hello Richard,

That might be a hint that userspace is also involved in the problem.
Does `aplay -l` still list the same devices as in the good state?
Does

	systemctl soft-reboot

also cure the problem?

Yes, that removes the USB controller, so all devices plugged into that
disappear.

Best regards
Uwe

Hi Uwe,


I'll try to test these the next time it happens, thanks for the suggestions. Right now I'm trying to only plug in headphones while I'm booted into a Fedora 42 live ISO. It's possible the tests with F41 failed because its Kernel is from before these issues started appearing.

Best regards

Richard

Hi Uwe,

I've got some interesting news. I now used Fedora 42 for 12 days without any issues. So today I started booting Ubuntu 25.04 from USB, and after just over an hour of usage the issue appeared. So whatever the cause is, it seems to be limited to Debian and its derivatives. while Fedora doesn't seem to be affected at all. So whatever the cause is, it's not due to anything I did, it's there by default.

I also tried your recommendations: aplay -l did in fact still show the expansion card, and so did lsusb. systemctl soft-reboot did not fix anything, though I'll check out both again the next time this issue happens on my Debian system.


Best regards

Richard

Hi Uwe,

On Wed, Jul 21, 2025 at 18:49:43PM +0200, Richard wrote:


Hi Uwe,

I've got some interesting news. I now used Fedora 42 for 12 days without any issues. So today I started booting Ubuntu 25.04 from USB, and after just over an hour of usage the issue appeared. So whatever the cause is, it seems to be limited to Debian and its derivatives. while Fedora doesn't seem to be affected at all. So whatever the cause is, it's not due to anything I did, it's there by default.

I also tried your recommendations: aplay -l did in fact still show the expansion card, and so did lsusb. systemctl soft-reboot did not fix anything, though I'll check out both again the next time this issue happens on my Debian system.


Best regards

Richard

It now also happened on Debian. aplay -l and lsusb still showed the expansion modue (I'm currently on kernel 6.15.7), systemctl soft-reboot plus unplugging and replugging the module did indeed help, audio worked again through it. Though soft-reboot was quite slow, about as slow as a full reboot, though I'm not sure if it would also take e.g. --force for a faster reboot.

Best regards
Richard

Hello Richard,
if the software restart was enough to fix the issue?  If yes that would
be a strong hint that this is a userspace issue.

Just to recap on earlier mails: Replugging the hardware alone didn't
help.

I wonder if in the broken state `aplay` is able to still playback
things. If that works that would be another indication that the
userspace software stack is involved.

Best regards
Uwe

Hi Uwe,
I did check. Before the soft-reboot no audio device showed up, after the soft-reboot only the AMD audio controller for the speakers. Only after replugging the module it reappeared.
Exactly, a soft-reboot plus replugging or a full reboot is required to show the module again.

I'll try that out the next time it happens. I've already prepared a wav audio file that aplay can play back.


Best regards

Richard

Hi Uwe,


I've tested that one too now, without any success. Not setting an output device makes it seem like it's playing something, but to cancel it, you need to press Ctrl+C twice for it to actually quit. When defining the output device to be the module (as far as I understand it), it says ressource busy. Also, this error message appears in the users journal:


xdg-desktop-por[3558]: Realtime error: Could not get pidns for pid 11688: Could not fstatat ns/pid: Not a directory


Also, recently Gnome started showing audio to be muted in the top bar when the audio outputs disappear, instead of still showing a volume level indicator.


Best regards

Richard

I've got some bad news, that may help figuring out where the issue lies though. I just went back to kernel 6.6.106 because of both this issue and several amdgpu issues. I thought it couldn't happen here, but it did. Wherever the source lies, it must have been backported to 6.6. I first set up my FW16 with Debian 12 back in late April 2024, but this issue didn't appear before kernel 6.9, maybe even with 6.10 or 6.11. While I'm not sure when exactly, it most certainly didn't appear before the second half of 2024, most likely only in Q4.


Best regards

Richard

Best regards

Richard

Hello,

So you compiled your own 6.6.106 kernel, right?

Hmm, v6.6.36 was released on 2024-06-27 and v6.6.37 on 2024-07-05. So
v6.6.36 is the latest commit where you are reasonably sure that it's
still good, right. Unfortunately there are more than 11000 commits
between v6.6.36 and 6.6.106.

If the problem was easier to reproduce, I'd ask for bisection. But given
that you can only diagnose that a kernel is bad but not that it's good,
maybe do a bisect that I'd call a 90:10 bisection. That is, instead of
picking the middle between known good and known bad, pick a rev that is
much nearer to the bad commit to test. So in a first step maybe test
6.6.102 or so.

(Of course running an old stable kernel for a time long enough to be
able to trigger that problem is risky. So ideally do that in a known
good network and with proper backups.)

Best regards
Uwe

Hi,
I actually never tried a 6.6 kernel before, I'm only quite sure it started showing up with 6.10 or 6.11, more likely 6.10, but it's not impossible it was with 6.9. and yes, I compiled straight from upstream sources.

There are definitely now more people in my Framework community post that started seeing this with Debian 13 or Ubuntu 25.04., but that sadly won't help that much with bisecting either. The only thing I can say is that whatever change was backported to 6.6, it is probably the worst trigger I've yet encountered, it will pretty much happen at least on a daily basis and can even happen multiple times per day.

Testing previous kernel versions shouldn't be that difficult, "ideally" it will just be a matter of hours. Thankfully 6.6 isn't old stable but LTS.

Best regards
Richard

Hi,

I've got some news from some weeks of testing. It seems that Fedora must have ditched their fix when they moved from the 6.14 kernel line used originally in F42 to 6.15. Fedora's kernel 6.14.11 was the last I was able to verify the issue to be prevented. But it seems the Debian kernel "6.12.48+deb13-amd64" (and probably its successors) now carries a fix for this. I've used that kernel now for almost 14 days without the issue appearing even one time. Updating the linux-image-amd64 meta package to the latest version for Testing (6.17.8), it immediately reappeared. So whatever patch was added, it would be great if it was upstreamed.


Best greetings

Richard