* Re: potential bug or quirk in the linux kernel usb subsystem, usb microphone sampling rate resolution rate
From: Greg KH @ 2026-03-08 17:36 UTC (permalink / raw)
To: Hans Jörg Paliege; +Cc: linux-usb, linux-hotplug
In-Reply-To: <159da401-4f3a-4069-bd2a-d8dd934995e1@web.de>
On Wed, Mar 04, 2026 at 07:55:13PM +0100, Hans Jörg Paliege wrote:
> Hello Mr. Kroah-Hartman,
>
>
>
> my name is Hans Paliege and i am a longtime Linux user, but i came across a
> potential peculiar quirk or bug in the usb subsystem
>
> that may need your attention. According to the kernel documentation i should
> contact You as the main developer directly.
The documentation should say to contact the linux-usb list, which I've
cc:ed here :)
> I am using a debian unstable amd64 build that is updated daily, and during
> boot for about two weeks now
>
> the audio frequency sample rate of my logitech C270 usb webcam is no longer
> initialized correctly.
When did it last work properly? When did it stop working? Any specific
kernel version ranges?
> As a result the webcam only delivers video but no audio. The webcam
> microphone is as a audio device recognized
> by the webbrowser but the input is null.
Those are 2 different USB devices in one, so something is off for the
audio stream somehow.
>
> During boot the dmesg error messages are:
>
>
> [ +0,007125] usb 3-1: current rate 24000 is different from the runtime rate
> 16000
> [ +0,002572] usb 3-1: 3:3: cannot set freq 24000 to ep 0x82
>
>
>
> After manual usbreset of the logitech C270 webcam the dmesg error messages
> are:
>
>
> [Mär 2 22:13] usb 3-6.2: reset full-speed USB device number 7 using xhci_hcd
> [ +12,959814] usb 3-1: reset high-speed USB device number 2 using xhci_hcd
> [ +0,288046] uvcvideo 3-1:1.0: Found UVC 1.00 device C270 HD WEBCAM
> (046d:0825)
> [ +0,036940] usb 3-1: current rate 16000 is different from the runtime rate
> 32000
> [ +0,063995] usb 3-1: current rate 24000 is different from the runtime rate
> 16000
> [ +0,061679] usb 3-1: 3:3: cannot set freq 24000 to ep 0x82
> [ +0,213449] usb 3-1: set resolution quirk: cval->res = 384
Is that the audio device, or the video device?
> After some internet search i could not find any specific command,
> application or grub boot parameter to manually set the rate to the runtime
> rate of 16000 or 32000.
>
> The quirk seems to be, that the sampling rate is automatically set to the
> value of 24000, while the actual working runtime rates are ignored.
>
> Any subsequent pipewire-alsa related audio volume and input/output works
> fine, and i have to use a really old ZOOM H2 usb microphone at 44100 that
> works for now.
>
> Maybe a recent change in the linux kernel or the usb subsytem caused this.
> It would be great if you could take a closer look at it and fix it.
A range of kernel versions here would be helpful, as would any other
kernel log messages.
thanks,
greg k-h
^ permalink raw reply
* Make ReBAR Great Again
From: Cristian Cocos @ 2026-03-08 19:35 UTC (permalink / raw)
To: linux-hotplug
The following is a suggestion for the Linux kernel devs.
Now that Thunderbolt eGPUs have become more common, it might be a good
idea to make the Linux kernel ReBAR-over-Thunderbolt friendly. This, I
contend, can be done by simply mimicking the system behavior at boot
time.
The current Thunderbolt eGPU *hotplug* sequence of events is this: BAR
2's hardware register powers up at 256 MB — the default size programmed
into the BAR's address decoder by Intel at the factory. The PCIe
Resizable BAR capability advertises support for up to 16 GB, but it's
passive — software must explicitly exercise it. When a Thunderbolt eGPU
is hotplugged at runtime, the kernel's PCI subsystem enumerates the new
device, reads the BAR at its 256 MB default, sizes the bridge windows
to match, and assigns addresses — all before any driver loads. The
ReBAR capability is never consulted(!) during this process.
A workaround is available for cold-plug scenarios only, and is
achieved by means of the **thunderbolt.host_reset=0** kernel parameter:
this preserves the BIOS's PCIe tunnel and BAR assignments from POST
(where the BIOS *does* exercise ReBAR). This delivers the full 16 GB
BAR but, as just mentioned, only works for cold-plug(!) scenarios — if
the eGPU is power-cycled at runtime, the new tunnel gets the 256 MB
default.
The proper fix would be for the kernel's PCI hotplug resource
assignment to *first* check for ReBAR capability during enumeration,
resize the BAR to the largest supported size that fits within available
bridge headroom, and *then* commit bridge windows and assign addresses.
This is essentially what the BIOS does during POST. It hasn't been
implemented yet because eGPU-over-Thunderbolt-with-ReBAR is (was?) a
niche use case.
Well, no more niche use case. eGPU-over-Thunderbolt is becoming
mainstream.
^ permalink raw reply
* Re Re: potential bug or quirk in the linux kernel usb subsystem, usb microphone sampling rate resolution rate
From: Hans Jörg Paliege @ 2026-03-09 9:04 UTC (permalink / raw)
To: linux-hotplug
Hello Mr. Hartman,
i am just a daily linux user and not familiar with the internal
proceedings of bugreports, mailing lists and development teams.
Please dont take any of this personal. I just sent the report to the
main developer according to the linux kernel documentation,
which is you. As with yesterdays and this email, i only clicked reply
and i hope that the email finds its way to the right developer
and with some good luck maybe this quirk will be fixed.
Small addendum to the usb microphone quirk:
As a workaround i use a professional ZOOM H2 usb audio recording device
from 2009. Specs can be found on a wikipedia page.
The main difference why this works fine is because during boot it is
only powered up and on the device itself i have to
choose either to be a smd card storage device or a usb stereo
microphone. At this point i have to manually set the
audio sample rate to either 44100 or 48000 and then initialize the usb
connection with the pc. Once this is done,
it works and the usb subsystem does not override the sampling rate
because it is set on the device itself.
As with todays dmesg messages, they are the same as yesterday. All other
dmesg messages are fine with no errors, and all other usb devices work
fine.
Thank you very much.
Best regards
Hans Paliege
^ permalink raw reply
* Re: Make ReBAR Great Again
From: Cristian Cocos @ 2026-03-26 15:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <b60b2f7c039f5f325fc54a75230f595a2278776b.camel@ieee.org>
Is this the right forum to post this? The hotplug list looked to me to
be the most appropriate venue, though please advise if you guys can
think of a more appropriate recipient.
The short story is that ReBAR does not work in hotplug scenarios:
hotplugged eGPUs are forced onto a 256MB BAR regardless of the system's
ReBAR capabilities, and this because during hotplug the Linux kernel
does not consult the ReBAR capability. It's that simple. Seeing as
eGPUs are becoming more popular, accommodating eGPU hotplug scenarios
becomes stringent.
On Sun, 2026-03-08 at 15:35 -0400, Cristian Cocos wrote:
> The following is a suggestion for the Linux kernel devs.
>
> Now that Thunderbolt eGPUs have become more common, it might be a
> good
> idea to make the Linux kernel ReBAR-over-Thunderbolt friendly. This,
> I
> contend, can be done by simply mimicking the system behavior at boot
> time.
>
> The current Thunderbolt eGPU *hotplug* sequence of events is this:
> BAR
> 2's hardware register powers up at 256 MB — the default size
> programmed
> into the BAR's address decoder by Intel at the factory. The PCIe
> Resizable BAR capability advertises support for up to 16 GB, but it's
> passive — software must explicitly exercise it. When a Thunderbolt
> eGPU
> is hotplugged at runtime, the kernel's PCI subsystem enumerates the
> new
> device, reads the BAR at its 256 MB default, sizes the bridge windows
> to match, and assigns addresses — all before any driver loads. The
> ReBAR capability is never consulted(!) during this process.
>
> A workaround is available for cold-plug scenarios only, and is
> achieved by means of the **thunderbolt.host_reset=0** kernel
> parameter:
> this preserves the BIOS's PCIe tunnel and BAR assignments from POST
> (where the BIOS *does* exercise ReBAR). This delivers the full 16 GB
> BAR but, as just mentioned, only works for cold-plug(!) scenarios —
> if
> the eGPU is power-cycled at runtime, the new tunnel gets the 256 MB
> default.
>
> The proper fix would be for the kernel's PCI hotplug resource
> assignment to *first* check for ReBAR capability during enumeration,
> resize the BAR to the largest supported size that fits within
> available
> bridge headroom, and *then* commit bridge windows and assign
> addresses.
> This is essentially what the BIOS does during POST. It hasn't been
> implemented yet because eGPU-over-Thunderbolt-with-ReBAR is (was?) a
> niche use case.
>
> Well, no more niche use case. eGPU-over-Thunderbolt is becoming
> mainstream.
>
>
^ permalink raw reply
* Re: Make ReBAR Great Again
From: Greg KH @ 2026-03-26 15:16 UTC (permalink / raw)
To: Cristian Cocos; +Cc: linux-hotplug
In-Reply-To: <ec7dbc9aeab3f7e497ba6e10712da047cf5bc14e.camel@ieee.org>
On Thu, Mar 26, 2026 at 11:01:02AM -0400, Cristian Cocos wrote:
> Is this the right forum to post this? The hotplug list looked to me to
> be the most appropriate venue, though please advise if you guys can
> think of a more appropriate recipient.
linux-pci?
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox