HI Uwe,
On 26.06.25 18:21, Uwe Kleine-König wrote:
Hello Richard,
On Tue, Jun 24, 2025 at 06:09:05PM +0200, Richard wrote:
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.
[...]
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
-bash: echo: write error: No such device
I would expect
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
.
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.
So, not sure what the cause is. You mentioned I could also try to restart the
driver of the whole hub. But how would I do so? The expansion card is on bus 1
with three entries:
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
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
