Hi Uwe,
On 02.07.25 09:31, Uwe Kleine-König wrote:
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.
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.
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
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
