New: USB cannot submit urb disconnecting sound card

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: [email protected]
          Reporter: [email protected]
        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.

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

Niklas Neronin ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Niklas Neronin ([email protected]) --- (In reply to Evgenii from comment #0)

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.

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.

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

Mathias Nyman ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected]
                   |                            |om

--- Comment #2 from Mathias Nyman ([email protected]) --- 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.

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

--- Comment #3 from Evgenii ([email protected]) ---
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.

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

--- Comment #4 from Evgenii ([email protected]) ---
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.