[Bug 220307] New: USB cannot submit urb disconnecting sound card

[Bug 220307] New: USB cannot submit urb disconnecting sound card

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220307

            Bug ID: 220307
           Summary: USB cannot submit urb disconnecting sound card
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: drivers_usb@kernel-bugs.kernel.org
          Reporter: targz@rambler.ru
        Regression: No

Just got an error that looks like that in dmesg. Not sure what made it such,
just using sound card with Pipewire on 192000 Hz, 53 samples quantization. This
leads to about 0,275 ms delay while preparation of node to play sound takes
about 0,250 ms when VLC starts playing a video. Pw-top reports about 0,3 ms
delay in Busy field if that matters. With 64 samples there was no issues with
preparing the node to start playing and had no conflict with hardware using
standard Arch kernel 6.15-4-arch2-1. So seems this is a USB bug when sound card
drops off and gets up stopping playback of sound while video goes further.

[  321.031944] usb 1-9: USB disconnect, device number 4
[  321.032030] xhci_hcd 0000:00:14.0: Event dma 0x000000015a8ee570 for ep 5
status 1 not part of TD at 000000015a8ee580 - 000000015a8ee580
[  321.032032] xhci_hcd 0000:00:14.0: Ring seg 0 dma 0x000000015a8ee000
[  321.032033] xhci_hcd 0000:00:14.0: Ring seg 1 dma 0x000000015a8ef000
[  321.032037] usb 1-9: cannot submit urb (err = -19)
[  321.274920] usb 1-9: new high-speed USB device number 11 using xhci_hcd
[  321.779252] usb 1-9: New USB device found, idVendor=0d8c, idProduct=0268,
bcdDevice= 2.03
[  321.779256] usb 1-9: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[  321.779256] usb 1-9: Product: BOMGE USB Audio Device
[  321.779257] usb 1-9: Manufacturer: C-Media Electronics Inc.
[  322.551132] input: C-Media Electronics Inc. BOMGE USB Audio Device as
/devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.3/0003:0D8C:0268.000C/input/input29
[  322.602843] hid-generic 0003:0D8C:0268.000C: input,hidraw2: USB HID v1.11
Device [C-Media Electronics Inc. BOMGE USB Audio Device] on
usb-0000:00:14.0-9/input3
[  422.601815] /proc/cgroups lists only v1 controllers, use cgroup.controllers
of root cgroup for v2 info

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 220307] USB cannot submit urb disconnecting sound card

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220307

Niklas Neronin (niklas.neronin@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |niklas.neronin@gmail.com

--- Comment #1 from Niklas Neronin (niklas.neronin@gmail.com) ---
(In reply to Evgenii from comment #0)
> Just got an error that looks like that in dmesg. Not sure what made it such,
> just using sound card with Pipewire on 192000 Hz, 53 samples quantization.
> This leads to about 0,275 ms delay while preparation of node to play sound
> takes about 0,250 ms when VLC starts playing a video. Pw-top reports about
> 0,3 ms delay in Busy field if that matters. With 64 samples there was no
> issues with preparing the node to start playing and had no conflict with
> hardware using standard Arch kernel 6.15-4-arch2-1. So seems this is a USB
> bug when sound card drops off and gets up stopping playback of sound while
> video goes further.
> 
> [  321.031944] usb 1-9: USB disconnect, device number 4
> [  321.032030] xhci_hcd 0000:00:14.0: Event dma 0x000000015a8ee570 for ep 5
> status 1 not part of TD at 000000015a8ee580 - 000000015a8ee580
> [  321.032032] xhci_hcd 0000:00:14.0: Ring seg 0 dma 0x000000015a8ee000
> [  321.032033] xhci_hcd 0000:00:14.0: Ring seg 1 dma 0x000000015a8ef000

Looks like the we receive a Transfer Event with Transfer Event with a
completion
status of "Success," but its corresponding TD is no longer in the driver's
internal list.

> [  321.032037] usb 1-9: cannot submit urb (err = -19)

USB-audio driver can still submit URBs while the device is being disconnected,
resulting in this harmless error message.

It's hard to tell from this short log what may be causing this issue.
The root cause probably occurred before this snippet.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 220307] USB cannot submit urb disconnecting sound card

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220307

Mathias Nyman (mathias.nyman@linux.intel.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mathias.nyman@linux.intel.c
                   |                            |om

--- Comment #2 from Mathias Nyman (mathias.nyman@linux.intel.com) ---
Any chance you could take xhci traces of this, with additional xhci dynamic
debug added.
It should show in detail every TRB queued to the ring, and each event for it.

Steps:
mount -t debugfs none /sys/kernel/debug
echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
echo 1 > /sys/kernel/debug/tracing/tracing_on
< Reproduce issue >
Send output of dmesg
Send content of /sys/kernel/debug/tracing/trace

The trace grows fast, so please try to copy it as soon as possible
after issue is reproduced.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 220307] USB cannot submit urb disconnecting sound card

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220307

--- Comment #3 from Evgenii (targz@rambler.ru) ---
This was probably Bomge U202 internal bug, cause when I've got this I been
using this audio interface, but currently using another one. Still I've seen
another issues in dmesg, so maybe with time would be able to catch that bug.
That happened on MSI Z790-A motherboard with its USB controller on a system
with DDR5 working in Gear 1 mode, so that might affect my experience, but I
only seen a bug once when system dropped its state and had to train memory
again to make that work on 5200 MHz overclocked state, so now I just using RAM
without overclocking, cause during summer RAM already at about 35 degrees
instead of about 28. And officially Intel don't support DDR5 in Gear 1 mode,
but here my proof that its able to work and probably the only way to save
LGA1851 socket cause there are broken UMC instead of IMC as on LGA1700. There
are Intel memory latency testing shown on the video, so I guess you might trust
at least to own tools. Telling this cause errors one thing, but conditions is
another and you cannot get help from Russians.

https://www.youtube.com/watch?v=bn2xNHynLfI

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 220307] USB cannot submit urb disconnecting sound card

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220307

--- Comment #4 from Evgenii (targz@rambler.ru) ---
Mathias I already tried to contact Intel about DDR5, bug they prefer to don't
answer making view that this is not possible I guess. But what not possible for
Intel engineers doesn't mean not possible for me. I just had some issues
running Firefox for example when its crashing on start when I've used test
settings for overclocked DDR5 in Gear 1 working on frequency of memory
controller - that's why I'm not dropping this as possibility for issues in
Linux, while games running just fine. I been able to heat up up to about 52
degrees RAM using testmem5, the original one - not newer versions that simply
not launch on Linux, but in games it stays pretty much cold cause no voltage
overload happens on PMIC. And practically this is world record in overclocking
about what again don't wish to know western society I guess cause its not
comfortable to tell everyone that they are not best in overclocking the RAM
that is not promoting high speeds cause in reality Gear 1 requires not that
much voltages and might work on simpler motherboards - again against interests
of motherboards makers I guess. But in reality this is the only way how Intel
could stop firing employees by thousands - is to use platform capabilities.
This also might be extremely important not only for games, but also servers
which Linux also targeting. If you are able to recognize proper work of Intel
MLC in terminal you might explain that to your bosses that prefers to close
eyes on reality if your company would not fire you as they closed own Linux
distribution recently. Maybe bugs happening cause of unsupported state, maybe
not. My experience is limited, but still there is no one better who could
handle DDR5 on Intel platform. For me it works fine and even if latency not
getting reduced in 5400 MHz mode versus 5200 MHz mode Geekbench shows equal
performance benefit. So I don't understand Intel strategy to ruin Gear 1
support cause life shows that my strategy works better.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.