Hi Luiz,
Sorry for the late response.
On Thu, 2025-03-13 at 09:08 +0100, Paul Menzel wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> [Cc: +regressions, commit ccfc8948d7e4 was added in v6.11-rc1]
>
> Am 13.03.25 um 02:43 schrieb Benedikt Ziemons:
> > On Tue, 2025-03-11 at 21:53 -0400, Luiz Augusto von Dentz wrote:
>
> > > On Mon, Mar 10, 2025 at 5:24 PM Geraldo Nascimento wrote:
> > > >
> > > > On Sun, Mar 09, 2025 at 06:02:11AM +1030, Geoffrey D. Bennett
> > > > wrote:
> > > > > This series (choose 1 of the 2 patches) addresses an issue
> > > > > where the
> > > > > MT7922 Bluetooth controller reset added in commit
> > > > > ccfc8948d7e4
> > > > > ("Bluetooth: btusb: mediatek: reset the controller before
> > > > > downloading
> > > > > the fw") is causing Focusrite USB audio devices to fail to
> > > > > initialise
> > > > > when connected during boot on kernels 6.11 and newer.
> > > > >
> > > > > Reported by three users here:
> > > > > https://urldefense.com/v3/__https://github.com/geoffreybennett/linux-fcp/issues/24__;!!CTRNKA9wMg0ARbw!hovfaKcQBzFKUu7X62SNU_berXiuXtSb2ndXGjAyf9WCptdz3D8jnprUqYc6b2fQE_3zrt88nGpKtJcYUCCcdA$
> > > > >
> > > > > Two users confirmed they have an MT7922.
> > > > >
> > > > > I'm providing two possible solutions as I note there was a
> > > > > similar
> > > > > change made in commit a7208610761a ("Bluetooth: btmtk: Remove
> > > > > resetting mt7921 before downloading the fw"), so I'm not sure
> > > > > if the
> > > > > reset should be reverted for the MT7925 as well as the
> > > > > MT7922.
> > > > >
> > > > > Option 1: Revert the problematic reset behaviour entirely
> > > > > (MT7922 +
> > > > > MT7925)
> > > > >
> > > > > Option 2: Remove the reset only for the MT7922
> > > > >
> > > > > Geoffrey D. Bennett (2):
> > > > >
> > > > > [PATCH 1/2] Revert "Bluetooth: btusb: mediatek: reset the
> > > > > controller
> > > > > before downloading the fw"
> > > > >
> > > > > [PATCH 2/2] Bluetooth: btmtk: Remove resetting mt7922
> > > > > before
> > > > > downloading the fw
> > > > >
> > > > > --
> > > > > 2.45.0
> > > > >
> > > > >
> > > >
> > > > Hi Geoffrey,
> > > >
> > > > I understand there's no apparent nexus of causality here.
> > > >
> > > > However if three different users suddenly reported the same
> > > > problem
> > > > and the fix fixes it, we should take the report seriously and
> > > > back
> > > > down on the problematic commit until we figure for sure what
> > > > the heck
> > > > is going on.
> > > >
> > > > My bet is this is bona fide bug in the USB subsystem, but
> > > > either I'm
> > > > not looking hard enough or I'm looking into the wrong places,
> > > > because
> > > > there's no way I can see in which way USB bluetooth driver from
> > > > MediaTek could cause clock detection to fail.
> > > >
> > > > No point in pressing this harder, but yeah, take the reports
> > > > more than
> > > > seriously, because if we don't understand in which way our own
> > > > (Linux)
> > > > code could be causing this, at least we should take cautionary
> > > > measures.
> > > >
> > > > In that sense, putting Takashi Iwai and Greg KH to Cc: in a
> > > > modest but
> > > > sincere belief that this issue is more than real, even though
> > > > it looks
> > > > like anticipated April 1st. Takashi can help with his expertise
> > > > in
> > > > clock detection and Greg could help pinpoint if this is indeed
> > > > madness
> > > > in the USB subsystem.
> > > >
> > > > Hope you and them don't mind the escalation :)
> > >
> > > Do you guys have any idea what could be possibly going on here?
> > > There
> > > really seems something is not right if one driver affects the
> > > other,
> > > especially if the devices are not actually related in any way.
>
I've discussed internally with Sean and Hao from MediaTek who submit
the changes to Kernel. The original intention was to ensure
controller's status is clean before Bluetooth driver doing firmware
binary download when booting. However, it seems that the changes cause
unexpected USB device enumeration problem at this timing with specific
USB devices.
To avoid such problem, we also agree that reverting those changes would
be a better choice. Thanks a lot.
> > I did the kernel bisection on this issue and tested Geoffrey's
> > patches
> > since I own the affected combination of hardware and can reliably
> > reproduce the issue.
> >
> > I was now able to capture both the sound device initialization
> > failure
> > and the successful initialization from initramfs using the usbmon
> > module. One difference that is immediately noticeable is the amount
> > of
> > URB_CONTROL data that is sent to the mediatek btusb device and a
> > considerable slow-down of the boot process (around 16s difference).
> >
> > Following is some more information about the timing and other
> > related
> > messages from the kernel message log. The first excerpt is from an
> > unpatched kernel 6.14.0-rc5:
> >
> > [ 59.987242] lunar kernel: usb 1-2: new high-speed USB device
> > number 2 using xhci_hcd
> > [ 59.987975] lunar kernel: usb 1-2: New USB device found,
> > idVendor=1235, idProduct=8212, bcdDevice= 6.45
> > [ 59.988048] lunar kernel: usb 1-2: New USB device strings:
> > Mfr=1, Product=3, SerialNumber=2
> > [ 59.988121] lunar kernel: usb 1-2: Product: Scarlett 4i4 USB
> > [ 59.988197] lunar kernel: usb 1-2: Manufacturer: Focusrite
> > [ 60.571193] lunar kernel: mt7921e 0000:0a:00.0: enabling device
> > (0000 -> 0002)
> > [ 60.571314] lunar kernel: mt7921e 0000:0a:00.0: ASIC revision:
> > 79220010
> > [ 60.571501] lunar kernel: usbcore: registered new interface
> > driver btusb
> > [ 60.571513] lunar kernel: mt7921e 0000:0a:00.0: HW/SW Version:
> > 0x8a108a10, Build Time: 20241106163228a
> > [ 60.571627] lunar kernel: mt7921e 0000:0a:00.0: WM Firmware
> > Version: ____000000, Build Time: 20241106163310
> > [ 60.616673] lunar kernel: Bluetooth: hci0: HW/SW Version:
> > 0x008a008a, Build Time: 20241106163512
> > [ 64.549017] lunar kernel: mt7921e 0000:0a:00.0 wlp10s0: renamed
> > from wlan0
> > [ 70.700407] lunar kernel: usb 1-2:
> > parse_audio_format_rates_v2v3(): unable to retrieve number of
> > sample rates (clock 41)
> > [ 81.264360] lunar kernel: usb 1-2:
> > parse_audio_format_rates_v2v3(): unable to retrieve number of
> > sample rates (clock 41)
> > [ 81.264611] lunar kernel: usb 1-2: Focusrite Scarlett Gen 3
> > Mixer Driver enabled (pid=0x8212); report any issues to
> > https://urldefense.com/v3/__https://github.com/geoffreybennett/scarlett-gen2/issues__;!!CTRNKA9wMg0ARbw!hovfaKcQBzFKUu7X62SNU_berXiuXtSb2ndXGjAyf9WCptdz3D8jnprUqYc6b2fQE_3zrt88nGpKtJe1OM82_Q$
> > [ 81.264782] lunar kernel: usb 1-2: Error initialising Scarlett
> > Gen 3 Mixer Driver: -71
> > [ 81.264903] lunar kernel: snd-usb-audio 1-2:1.0: probe with
> > driver snd-usb-audio failed with error -71
> > [ 81.265040] lunar kernel: usb 1-2: Quirk or no altset; falling
> > back to MIDI 1.0
> > [ 81.400030] lunar kernel: Bluetooth: hci0: Device setup in
> > 20435397 usecs
> > [ 81.400114] lunar kernel: Bluetooth: hci0: HCI Enhanced Setup
> > Synchronous Connection command is advertised, but not supported.
> > [ 81.680052] lunar kernel: Bluetooth: hci0: AOSP extensions
> > version v1.00
> > [ 81.680170] lunar kernel: Bluetooth: hci0: AOSP quality report
> > is supported
> > [ 87.373353] lunar kernel: usbcore: registered new interface
> > driver snd-usb-audio
> >
> >
> > The following second excerpt is from the same kernel version with
> > Geoffrey's second patch applied:
> >
> > [ 139.603887] lunar kernel: usb 1-2: new high-speed USB device
> > number 2 using xhci_hcd
> > [ 139.604524] lunar kernel: usb 1-2: New USB device found,
> > idVendor=1235, idProduct=8212, bcdDevice= 6.45
> > [ 139.604598] lunar kernel: usb 1-2: New USB device strings:
> > Mfr=1, Product=3, SerialNumber=2
> > [ 139.604672] lunar kernel: usb 1-2: Product: Scarlett 4i4 USB
> > [ 139.604744] lunar kernel: usb 1-2: Manufacturer: Focusrite
> > [ 140.192488] lunar kernel: usbcore: registered new interface
> > driver btusb
> > [ 140.192501] lunar kernel: mt7921e 0000:0a:00.0: enabling device
> > (0000 -> 0002)
> > [ 140.192627] lunar kernel: Bluetooth: hci0: HW/SW Version:
> > 0x008a008a, Build Time: 20241106163512
> > [ 140.192639] lunar kernel: mt7921e 0000:0a:00.0: ASIC revision:
> > 79220010
> > [ 140.192753] lunar kernel: mt7921e 0000:0a:00.0: HW/SW Version:
> > 0x8a108a10, Build Time: 20241106163228a
> > [ 140.192866] lunar kernel: mt7921e 0000:0a:00.0: WM Firmware
> > Version: ____000000, Build Time: 20241106163310
> > [ 140.240011] lunar kernel: Bluetooth: hci0: Device setup in
> > 188119 usecs
> > [ 140.240048] lunar kernel: Bluetooth: hci0: HCI Enhanced Setup
> > Synchronous Connection command is advertised, but not supported.
> > [ 140.513341] lunar kernel: Bluetooth: hci0: AOSP extensions
> > version v1.00
> > [ 140.513379] lunar kernel: Bluetooth: hci0: AOSP quality report
> > is supported
> > [ 144.115475] lunar kernel: mt7921e 0000:0a:00.0 wlp10s0: renamed
> > from wlan0
> > [ 144.115747] lunar kernel: usb 1-2: Focusrite Scarlett Gen 3
> > Mixer Driver enabled (pid=0x8212); report any issues to
> > https://urldefense.com/v3/__https://github.com/geoffreybennett/scarlett-gen2/issues__;!!CTRNKA9wMg0ARbw!hovfaKcQBzFKUu7X62SNU_berXiuXtSb2ndXGjAyf9WCptdz3D8jnprUqYc6b2fQE_3zrt88nGpKtJe1OM82_Q$
> > [ 144.115857] lunar kernel: usb 1-2: Firmware version 1605
> > [ 144.115954] lunar kernel: usb 1-2: Quirk or no altset; falling
> > back to MIDI 1.0
> > [ 147.843340] lunar kernel: usbcore: registered new interface
> > driver snd-usb-audio
> >
> >
> > Comparing the USB captures from the hub, filtered to just the first
> > few
> > messages of the audio device yield the following exchanges. Again,
> > first the broken case:
> >
> > No. Time Source Destination
> > Protocol Length Info
> > 7 0.011098 host 1.2.0
> > USB 64 GET DESCRIPTOR Request DEVICE
> > 8 0.015218 1.2.0 host
> > USB 82 GET DESCRIPTOR Response DEVICE
> > 9 0.015272 host 1.2.0
> > USB 64 GET DESCRIPTOR Request CONFIGURATION
> > 10 0.017966 1.2.0 host
> > USB 73 GET DESCRIPTOR Response CONFIGURATION
> > 11 0.018020 host 1.2.0
> > USB 64 GET DESCRIPTOR Request CONFIGURATION
> > 12 0.025965 1.2.0 host
> > USB 425 GET DESCRIPTOR Response CONFIGURATION
> > 23 2.482241 host 1.2.0
> > USB 64 GET DESCRIPTOR Request STRING
> > 24 2.484931 1.2.0 host
> > USB 98 GET DESCRIPTOR Response STRING
> > 25 2.484939 host 1.2.0
> > USB 64 GET DESCRIPTOR Request STRING
> > 26 2.487916 1.2.0 host
> > USB 84 GET DESCRIPTOR Response STRING
> > 27 2.487941 host 1.2.0
> > USBAUDIO 65 SET CUR CX_CLOCK_SELECTOR_CONTROL request
> > 2047 7.661154 1.2.0 host
> > USBAUDIO 64 SET CUR CX_CLOCK_SELECTOR_CONTROL status
> > 2048 7.661197 host 1.2.0
> > USBAUDIO 64 GET RANGE CS_SAM_FREQ_CONTROL request
> > 4097 12.781553 1.2.0 host
> > USBAUDIO 64 GET RANGE CS_SAM_FREQ_CONTROL[Malformed Packet]
> >
> >
> > The first discrepancy can be found in the URB status field of
> > packet
> > no. 2047 (vs. 74 below) which is -2: No such file or directory (-
> > ENOENT).
> > In the second (following) case where the sound device initializes
> > okay, the URB status of the similar packet is Success (0) instead:
> >
> > No. Time Source Destination
> > Protocol Length Info
> > 7 0.011565 host 1.2.0
> > USB 64 GET DESCRIPTOR Request DEVICE
> > 8 0.015471 1.2.0 host
> > USB 82 GET DESCRIPTOR Response DEVICE
> > 9 0.015523 host 1.2.0
> > USB 64 GET DESCRIPTOR Request CONFIGURATION
> > 10 0.018477 1.2.0 host
> > USB 73 GET DESCRIPTOR Response CONFIGURATION
> > 11 0.018537 host 1.2.0
> > USB 64 GET DESCRIPTOR Request CONFIGURATION
> > 12 0.026331 1.2.0 host
> > USB 425 GET DESCRIPTOR Response CONFIGURATION
> > 23 4.168190 host 1.2.0
> > USB 64 GET DESCRIPTOR Request STRING
> > 24 4.171031 1.2.0 host
> > USB 98 GET DESCRIPTOR Response STRING
> > 25 4.171040 host 1.2.0
> > USB 64 GET DESCRIPTOR Request STRING
> > 26 4.174021 1.2.0 host
> > USB 84 GET DESCRIPTOR Response STRING
> > 27 4.174041 host 1.2.0
> > USBAUDIO 65 SET CUR CX_CLOCK_SELECTOR_CONTROL request
> > 74 4.476033 1.2.0 host
> > USBAUDIO 64 SET CUR CX_CLOCK_SELECTOR_CONTROL status
> > 75 4.476050 host 1.2.0
> > USBAUDIO 64 GET CUR CX_CLOCK_SELECTOR_CONTROL request
> > 76 4.479034 1.2.0 host
> > USBAUDIO 65 GET CUR CX_CLOCK_SELECTOR_CONTROL response
> > 77 4.479050 host 1.2.0
> > USBAUDIO 64 GET RANGE CS_SAM_FREQ_CONTROL request
> > 202 4.582043 1.2.0 host
> > USBAUDIO 66 GET RANGE CS_SAM_FREQ_CONTROL response
> >
> >
> > Please ask, if I should provide any more information or how and to
> > whom
> > I can provide the full USB captures.
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]
