Hello Richard, On Thu, Jun 26, 2025 at 07:16:31PM +0200, Richard wrote: > On 26.06.25 18:21, Uwe Kleine-König wrote: > > On Tue, Jun 24, 2025 at 06:09:05PM +0200, Richard wrote: > > > [...] > > > 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. > > > 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. 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. > > > 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 > > > 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) 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
Attachment:
signature.asc
Description: PGP signature