[Responded] Audio expansion card connection sometimes unreliable

Framework Laptop 16 Linux
1

Which Linux distro are you using? Debian

Which release version? Testing

Which kernel are you using? 6.12.8

Which BIOS version are you using? 3.05

Which Framework Laptop 16 model are you using? (AMD Ryzen™ 7040 Series) Ryzen 7 7840HX

While I always boot with the Audio expansion card inserted, sometimes Debian either forgets it ot refuses to use it after a while, not sure. Plugging anything into it just isn’t registered by the system. Unplugging it and plugging it back in leads to these log messages (with headphones plugged in):

Jan 08 18:38:40 kernel: usb 1-2.2: new high-speed USB device number 14 using xhci_hcd
Jan 08 18:38:40 kernel: usb 1-2.2: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
Jan 08 18:38:40 kernel: usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 08 18:38:40 kernel: usb 1-2.2: Product: Audio Expansion Card
Jan 08 18:38:40 kernel: usb 1-2.2: Manufacturer: Framework
Jan 08 18:38:40 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/input27
Jan 08 18:38:40 kernel: hid-generic 0003:32AC:0010.000E: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2
Jan 08 18:38:40 mtp-probe[16512]: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2"
Jan 08 18:38:40 mtp-probe[16512]: bus: 1, device: 14 was not an MTP device

And when unplugging these:

Jan 08 18:42:14 framework16 kernel: usbhid 1-2.2:1.2: can't add hid device: -71
Jan 08 18:42:14 framework16 kernel: usbhid 1-2.2:1.2: probe with driver usbhid failed with error -71
Jan 08 18:42:14 framework16 kernel: usb 1-2.2: USB disconnect, device number 15

Is there a solution for this?

3

Please read the whole post. I never claimed this happens 100 % of the time, it happened sometimes, randomly and seemingly only after a while of running. So booting any live ISO will hardly be a suitable testing environment.

4

ive had some issues with the audio expansion card on fedora which ive chalked up to the cable not being fully inserted, but im not certain now.

it should be noted that to save power (at least this is the most logical explanation for the behaviour ive observed in the past, before i started having issues) the audio expansion card disconnects itself until it detects a cable plugged into it.

5

That power saving thing may be true, but then it should work when unplugging the module and plugging it back in. But so far only a reboot can fix it.

7

I guess the OP is saying booting it to a the live image to try to reproduce something intermittent is a unfeasible task for them?

Not sure if they can use it long enough in a live environment to reproduce the issue other than leaving something playing 24x7 (which may not be feasible). And may not be representative of their work flow which may replicate the issue.

Either way, I do think it’s at least something they can try (leave it playing music or something) while they aren’t using the laptop (background music or video).

Can try it in both a live environment and their current one.

Honestly, I don’t understand the last sentence - OP’s response didn’t sound hostile - just wondering what a live environment can do to help with their issue. Perhaps my expanded text would help - meaning “it may not SEEM like it will help, but at least it will be another data point”.

But also, I would contact Framework to see they can replace the module.

OH, another good test it to use the expansion card on a different PC (same OS or not) - just to see if it’s an issue with the expansion card before reaching out to Framework.

Because it’s intermittent, and no one else having this issue, it might be an issue with the card itself…

FYI, I’m on Fedora 41 (just got 6.12.8) but I don’t use my headphones that often. I can’t test 6.12.8 since I just got it AND my FW16 is on it’s way back to Framework to look into my display issue.

All I can say is prior to 6.12.8 (6.12.7 and prior), I had no issues with detecting my headphones as I do plug and unplug it relatively often.

8

Booting any live ISO isn’t a usable approach, as the issue happens too randomly. If it was an issue where I just had to boot into it and have my results, sure. But I would have to run it for days to even have a chance of encountering it, and I can’t even tell if only putting the device to sleep instead of shutting down and powering on will even have the same result. So I had to render my FW 16 literally unusable for days or weeks, and it’s questionable if that would even result in a representative test, as it’s a live distro that’s not storing anything, which again can just make the results worthless.

So no, any live ISO can’t be a viable test, not to mention making my life for days or weeks stupidly difficult. My laptop isn’t just some secondary or tertiary device, it’s my one and only computer that I use daily. That’s why I even went with FW, as I will always expect for my computer to last around 10 years, or it’s just not worth its money. With being easily repairable and upgradable, I see FW as pretty much the last company that can guarantee longevity, instead of cheaping out more and more every year so consumers need to replace their devices more frequently.

9

im guessing when the issue occurs you dont see it in pavucontrol or alsamixer or any equivalent (i.e. its not a problem with it not being the default sound card)

10

Exactly my point. It doesn’t show up at all. If it just wasn’t select default I could easily switch from Gnome settings and call it a day. Would be annoying and I would have made a bug report, but I could live with it. But it’s more like Linux doesn’t know it’s an audio interface.

It seems the package called bolt is responsible to detect what kind of device it is, though it’s technically only for Thunderbolt 3 devices. At least that would be my guess as I have no clue what else does these things.

1 Like
11

hmm

it does at least seem to detect it as a usb device. i wouldnt really be able to say why its not seeing it as an audio device though.

only thing of note in the kernel logs you posted is that the computer is checking if it supports mobile transfer protocol when the device connects (slow protocol used to get photos and other files off mobile phones over usb) and decides its not, and then when the audio expansion card disconnects it seems to fail to add a device as a hid device (i wonder if usbhid is waiting on something that never completes, and just aborts when the device disconnects? rather out of my depth here, so just speculating).

does it even show up in lsusb when the issue happens? id half expect it to seeing as it shows up as a new usb device in the kernel logs and seems to enumerate correctly.

also i tested with my fedora install and i didnt get the cant add hid device error when disconnecting it, nor did i get the mtp-probe stuff, but i did get the log message from hid-generic. seems like something is causing the device probe to hang.

my dmesg output 
[12439.016939] usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd
[12439.186951] usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd
[12450.389356] usb 1-2.3: new high-speed USB device number 10 using xhci_hcd
[12450.506258] usb 1-2.3: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
[12450.506271] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12450.506275] usb 1-2.3: Product: Audio Expansion Card
[12450.506278] usb 1-2.3: Manufacturer: Framework
[12450.570194] input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c5:00.3/usb1/1-2/1-2.3/1-2.3:1.2/0003:32AC:0010.000D/input/input25
[12450.621962] hid-generic 0003:32AC:0010.000D: input,hidraw11: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c5:00.3-2.3/input2
[12450.639117] mc: Linux media interface: v0.10
[12450.864421] usbcore: registered new interface driver snd-usb-audio
[12475.754970] usb 1-2.3: USB disconnect, device number 10
12

You might try unloading and reloading the usbhid driver when this occurs, to see if that helps:

sudo modprobe -r usbhid; sudo modprobe usbhid
13

Good point. I hope that I remember it the next time it happens.

14

It doesn’t usually happen. I just tries again. This is from unplugging:

Jan 18 18:23:43 kernel: usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd
Jan 18 18:23:56 kernel: usb 1-2.2: USB disconnect, device number 17
Jan 18 18:23:56 keyd[1061]: DEVICE: removed        32ac:0010:00c7003e Framework Audio Expansion Card Consumer Control

and this from plugging back in:

Jan 18 18:24:49 kernel: usb 1-2.2: new high-speed USB device number 18 using xhci_hcd
Jan 18 18:24:49 kernel: usb 1-2.2: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
Jan 18 18:24:49 kernel: usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 18 18:24:49 kernel: usb 1-2.2: Product: Audio Expansion Card
Jan 18 18:24:49 kernel: usb 1-2.2: Manufacturer: Framework
Jan 18 18:24:49 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.001B/input/input31
Jan 18 18:24:49 kernel: hid-generic 0003:32AC:0010.001B: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2
Jan 18 18:24:49 mtp-probe[69285]: checking bus 1, device 18: "/sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2"
Jan 18 18:24:49 mtp-probe[69285]: bus: 1, device: 18 was not an MTP device
Jan 18 18:24:49 boltd[30961]: probing: started [1000]
Jan 18 18:24:49 keyd[1061]: DEVICE: removed        32ac:0010:00c7003e Framework Audio Expansion Card Consumer Control
Jan 18 18:24:49 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.001C/input/input32
Jan 18 18:24:49 fwupd[30988]: 17:24:49.980 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
Jan 18 18:24:49 kernel: hid-generic 0003:32AC:0010.001C: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2
Jan 18 18:24:50 mtp-probe[69305]: checking bus 1, device 18: "/sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2.2"
Jan 18 18:24:50 mtp-probe[69305]: bus: 1, device: 18 was not an MTP device
Jan 18 18:24:53 boltd[30961]: probing: timeout, done: [2800216] (2000000)

and this is how it’s listed in dmesg:

[Jan18 19:13] [Sa Jan 18 19:13:51 2025] usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd
[  +0,191998] [Sa Jan 18 19:13:51 2025] usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd
[Jan18 19:14] [Sa Jan 18 19:14:04 2025] usb 1-2.2: USB disconnect, device number 17
[ +12,315649] [Sa Jan 18 19:14:57 2025] usb 1-2.2: new high-speed USB device number 18 using xhci_hcd
[  +0,125143] [Sa Jan 18 19:14:57 2025] usb 1-2.2: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
[  +0,000019] [Sa Jan 18 19:14:57 2025] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0,000006] [Sa Jan 18 19:14:57 2025] usb 1-2.2: Product: Audio Expansion Card
[  +0,000005] [Sa Jan 18 19:14:57 2025] usb 1-2.2: Manufacturer: Framework
[  +0,262271] [Sa Jan 18 19:14:58 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.001B/input/input31
[  +0,052771] [Sa Jan 18 19:14:58 2025] hid-generic 0003:32AC:0010.001B: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2
[  +0,120396] [Sa Jan 18 19:14:58 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.001C/input/input32
[  +0,059933] [Sa Jan 18 19:14:58 2025] hid-generic 0003:32AC:0010.001C: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c1:00.3-2.2/input2

So it may be related to the issue, though it doesn’t happen that often.

15

Ok, it’s just happening again. I’m thinking now it’s some kind of software issue, as now no audio device is available. Not even when I connect bt headphones. And that’s just after listening to stuff via these headphones and then turning them off to use the headphone jack.
sudo modprobe -r usbhid; sudo modprobe usbhid doesn’t do anyting as everything indicates the device is corrently connected. Also, I tried systemctl --user restart pipewire.service pipewire-pulse.service wireplumber.service which didn’t help either, not even logging out and back in.

dmsegs shows this error quite often:

usb 1-2.2: 1:1: cannot set freq 48000 (v2/v3): err -110
usb 1-2.2: uac_clock_source_is_valid(): cannot get clock validity for id 9
16

It seems that when this issue occurs, shutting down/restarting the system takes very long, compared to any shutdown/restart when it didn’t show up before. Could that mean there’s some issue with e.g. the Kernel? And if so, how do I find out what exactly is taking this long and why? For bootup, we have tools like systemd-analyze blame. Is there something also for shutdowns?

17

Now with these error messages I’m convinced that there is a Kernel issue:
Feb 23 08:43:05 kernel: usb 1-2.2: uac_clock_source_is_valid(): cannot get clock validity for id 9
Feb 23 08:43:05 kernel: usb 1-2.2: clock source 9 is not valid, cannot use
Feb 23 08:43:10 kernel: usb 1-2.2: 1:3: cannot get freq (v2/v3): err -110
Feb 23 08:43:15 kernel: usb 1-2.2: 1:3: cannot set freq 48000 (v2/v3): err -110
Feb 23 08:43:24 kernel: usb 1-2.2: uac_clock_source_is_valid(): cannot get clock validity for id 9
Feb 23 08:43:24 kernel: usb 1-2.2: clock source 9 is not valid, cannot use
Feb 23 08:43:29 kernel: usb 1-2.2: 1:3: cannot get freq (v2/v3): err -110
Feb 23 08:43:35 kernel: usb 1-2.2: 1:3: cannot set freq 48000 (v2/v3): err -110
Feb 23 08:43:40 kernel: usb 1-2.2: uac_clock_source_is_valid(): cannot get clock validity for id 9
Feb 23 08:43:40 kernel: usb 1-2.2: clock source 9 is not valid, cannot use
Feb 23 08:43:45 kernel: usb 1-2.2: 1:3: cannot get freq (v2/v3): err -110
Feb 23 08:43:50 kernel: usb 1-2.2: 1:3: cannot set freq 48000 (v2/v3): err -110

Could one of the Linux team of Framework take a look at this? This is now with Kernel 6.12.15.

18

Howdy @Richard

Sorry to hear you’re having this much trouble with the audio expansion card. I do have some thoughts that can maybe help us narrow down the issue.

You mentioned that it sometimes coincides with total failure of audio on the system. Are any other devices typically plugged in when you’re booting, or any other devices connected that the system may be seen as an audio device, input or output? For example, regardless of hardware or distro I sometimes see this error you posted associated with a USB microphone I have.

usb 1-2.2: 1:1: cannot set freq 48000 (v2/v3): err -110

If this is an error that you’re only seeing from the Audio Expansion card, we may be able to look into the possiblity of this being a hardware fault after ruling out other possibilities.

I know you’ve expressed that the issue is too intermittent to manifest in a live USB reliably. However if it is at all possible and would not unreasonably disrupt your work flow, it would be helpful to temporarily use something like an external SSD as a boot drive to install an officially support distribution like Ubuntu or Fedora, or a community supported distribution like Arch or Linux Mint. We do not officially support Debian, and Debian Testing may have bugs we cannot reasonably account for.

My last thought is that often if I’m trying to see what may be holding up the shutdown process, I like to have a look system logs scoped for the time around shutdown. For that I’ll run:

journalctl -r -b1 -n100 > lastshutdown.txt

I tend to take a simple approach, so I use that command which prints the system log in reverse order, cuts it to just the previous boot, and then limits the file to just 100 log lines. Usually this gives me a lot of the information I need about what may be holding up the system during shutdown.

Again, sorry about the frustration with this, I know how annoying troubleshooting audio issues can be.

19

Only the DP module, but nothing is ever connected to it at boot time. And unless this issue happened and I reboot my laptop with my headphones connected, nothing is plugged in to the audio jack at boot time either. Also, the only headphones I connect use a 3 pole jack, so the microphones used in BT mode wouldn’t work via the jack anyway.

However if it is at all possible and would not unreasonably disrupt your work flow, it would be helpful to temporarily use something like an external SSD as a boot drive to install an officially support distribution like Ubuntu or Fedora, or a community supported distribution like Arch or Linux Mint. We do not officially support Debian, and Debian Testing may have bugs we cannot reasonably account for.

It would be a huge disruption, I’m explicitly not using any of the officially supported distros for a good reason. Though, since I’m quite convinced this may be a bug in the Kernel, just compiling 6.13 (and higher) from sources, based on the config file Debian uses for 6.12.x (as I see unrelated issues on other devices that may or may not be caused by a misconfiguration for 6.13 in the Debian experimental repo) wouldn’t be any effort at all. I would have to run these self-compiled Kernels for quite a while, as it seems to me every update in the 6.12.x lineup may change the frequency of doing this - or it may just be my immagination, also I can’t say if maybe 6.12.14 or .15 may already have fixed this, as it’s really only happening randomly with absolutely no consistent time period inbetween - but if my theory was correct, that would be by far the simplest way to confirm or discard that theory.

My last thought is that often if I’m trying to see what may be holding up the shutdown process, I like to have a look system logs scoped for the time around shutdown. For that I’ll run

Been there, done that. I wish I had seen anything of relevance, but both when this happens on my FW16 and - unrelatedly - on a different machine, nothing of relevance is being written to Linux’ logs about issues during shutdown. My guess is that since this long waiting is at a stage where I see the wallpeper that is set for grub, at that point at least the user land is already “dead”. I do not know if grub produces any logs at this stage, but there’s just nothing in journalctl.

I also do have some closing thoughts:

At least in one instance I was able to find an issue with fwupd that it did evidently slow down bootup. I couldn’t reproduce this issue, I can’t tell if there’s even the possibility this could be related. But I though I’d share it either way: failed to add device, maybe cause for slower boot · Issue #8469 · fwupd/fwupd · GitHub

Also, it’s possible that the longer shutdown/reboot cycle may be fixed with 6.12.15 (6.12.14 was never offered in a Debian repo as far as I can tell, so it may have been either way). At least last time it happened (just before my last post) the longer reboot time didn’t happen.

Last but not least, at least for one or two 6.12.x versions, I had the strange issue that after the reboot, no video would play in any program. Not some YouTube video in Firefox, not some local video in mpv. So I had to do another reboot to fix everything. No idea if there could be any connection, this is simply what I noticed.

20

It really didn’t take as long as I hoped it would for the issue to appear on 6.13.4. This time it didn’t just happen upon plugging in headphones, but during playback. Those are the logs

Mär 01 17:29:03 framework16 dbus-daemon[976]: [system] Activating via systemd: service name='org.freedesktop.fwupd' unit='fwupd.service' requested by ':1.303' (uid=109 pid=296626 comm="/usr/bin/fwupdmgr refresh")
Mär 01 17:29:03 framework16 kernel: SCSI subsystem initialized
Mär 01 17:29:05 framework16 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
Mär 01 17:29:05 framework16 boltd[1175]: probing: started [1000]
Mär 01 17:29:05 framework16 keyd[987]: DEVICE: removed        32ac:0010:00c7003e Framework Audio Expansion Card Consumer Control
Mär 01 17:29:08 framework16 boltd[1175]: probing: timeout, done: [2991781] (2000000)
Mär 01 17:29:23 framework16 kernel: usb 1-2.2: 1:0: usb_set_interface failed (-110)
Mär 01 17:29:31 framework16 kernel: usbhid 1-2.2:1.2: can't add hid device: -110
Mär 01 17:29:31 framework16 kernel: usbhid 1-2.2:1.2: probe with driver usbhid failed with error -110
Mär 01 17:29:31 framework16 fwupd[296639]: 16:29:31.323 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: failed to get GET_REPORT: failed to GetReport: USB error: Operation timed out [-7]
Mär 01 17:29:28 framework16 systemd[1]: fwupd-refresh.service: Failed with result 'exit-code'.
Mär 01 17:29:28 framework16 systemd[1]: Failed to start fwupd-refresh.service - Refresh fwupd metadata and update motd.
Mär 01 17:29:28 framework16 dbus-daemon[976]: [system] Failed to activate service 'org.freedesktop.fwupd': timed out (service_start_timeout=25000ms)
Mär 01 17:29:31 framework16 fwupd[296639]: 16:29:31.475 FuMain               Daemon ready for requests (locale en_US.UTF-8)
Mär 01 17:29:46 framework16 dbus-daemon[976]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service' requested by ':1.307' (uid=0 pid=296809 comm="sudo journalctl -e --system")
Mär 01 17:29:47 framework16 kernel: usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd
Mär 01 17:29:47 framework16 dbus-daemon[976]: [system] Successfully activated service 'net.reactivated.Fprint'
Mär 01 17:29:47 framework16 kernel: usb 1-4.1: reset full-speed USB device number 7 using xhci_hcd
Mär 01 17:30:01 framework16 CRON[296827]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Mär 01 17:30:01 framework16 CRON[296829]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Mär 01 17:30:01 framework16 CRON[296827]: pam_unix(cron:session): session closed for user root
Mär 01 17:30:08 framework16 rtkit-daemon[1865]: Supervising 10 threads of 7 processes of 1 users.
Mär 01 17:30:08 framework16 rtkit-daemon[1865]: Supervising 10 threads of 7 processes of 1 users.

And when trying to get it back by unplugging the whole module and plugging it back in, I got this message:
Mär 01 17:31:38 framework16 fwupd[296639]: 16:31:38.555 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: failed to get GET_REPORT: failed to GetReport: USB error: Operation timed out [-7]

flanked by several instances of

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

Howdy Richard,

After looking at these log snippets, I’d actually like to encourage you to open up an official support ticket. I’ve had the chance to do some experimenting with my own audio expansion card, but I have not been able to recreate this issue. You could attempt to use kernel 6.13.5 in some form, which we’ve noticed is a relatively stable driver version.

What stands out to me in particular about the logs you’ve most recently shared is that the device is getting timed out because of fwupd trying to check the firmware of the audio expansion card. Based on my own experience and knowledge with audio devices in Linux tells me that this is absolutely abnormal behavior for your Audio Expansion Card, which has me thinking that your unit may be suffering from some sort of factory defect.

The support process may require you to do some testing in a Live USB environment just to confirm that this is not a Debian specific issue, but my gut instinct says this most likely is specific to your audio expansion card.

I wish you the best of luck with the process, and hope you’re able to get this resolved to your satisfaction.

22

Been doing so pretty much since it came out. So I’d wait and see if that pops up again.