Hi Uwe,
On 29.05.25 18:44, Uwe Kleine-König wrote:
Hello Richard,
On Fri, Apr 25, 2025 at 07:37:23PM +0200, Richard wrote:
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.
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.
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.
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.
Your more recent reply to this bug means that the problem isn't solved?
Best regards
Uwe
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
