| Message ID | Z8ybO7DfeP3Ag9wz@m.b4.vu |
|---|---|
| Headers | show |
| Series | Fix for MediaTek reset affecting Focusrite audio interfaces | expand |
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://github.com/geoffreybennett/linux-fcp/issues/24 > > 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 :) Thanks, Geraldo Nascimento
Hi Chris, Sean, Hao, On Mon, Mar 10, 2025 at 5:24 PM Geraldo Nascimento <geraldogabriel@gmail.com> 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://github.com/geoffreybennett/linux-fcp/issues/24 > > > > 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.
On Tue, 2025-03-11 at 21:53 -0400, Luiz Augusto von Dentz wrote: > Hi Chris, Sean, Hao, > > On Mon, Mar 10, 2025 at 5:24 PM Geraldo Nascimento > <geraldogabriel@gmail.com> 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://github.com/geoffreybennett/linux-fcp/issues/24 > > > > > > 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. > > Hello everyone, 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://github.com/geoffreybennett/scarlett-gen2/issues [ 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://github.com/geoffreybennett/scarlett-gen2/issues [ 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. Thank you, Ben
On Thu, Mar 13, 2025 at 02:43:09AM +0100, Benedikt Ziemons wrote: > On Tue, 2025-03-11 at 21:53 -0400, Luiz Augusto von Dentz wrote: > > Hi Chris, Sean, Hao, > > > > On Mon, Mar 10, 2025 at 5:24 PM Geraldo Nascimento > > <geraldogabriel@gmail.com> 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://github.com/geoffreybennett/linux-fcp/issues/24 > > > > > > > > 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. > > > > > > Hello everyone, > > 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://github.com/geoffreybennett/scarlett-gen2/issues > [ 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://github.com/geoffreybennett/scarlett-gen2/issues > [ 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. > > Thank you, > Ben Hi Ben, This bit sticks out to me: > [ 81.400030] lunar kernel: Bluetooth: hci0: Device setup in 20435397 usecs 20 seconds to initialise bluetooth, vs. 188ms when not doing the reset: > [ 140.240011] lunar kernel: Bluetooth: hci0: Device setup in 188119 usecs Does it still take 20 seconds when the Scarlett is not plugged in at boot time? I presume lsusb -t shows both devices on the same USB bus? Thanks, Geoffrey.
[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://github.com/geoffreybennett/linux-fcp/issues/24 >>>> >>>> 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 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://github.com/geoffreybennett/scarlett-gen2/issues > [ 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://github.com/geoffreybennett/scarlett-gen2/issues > [ 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.
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.
On Thu, Mar 13, 2025 at 09:05:16AM +0000, Chris Lu (陸稚泓) wrote: > 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. Great, can someone please submit the reverts? thanks, greg k-h
Hi Geoffrey, On Thu, 2025-03-13 at 17:43 +1030, Geoffrey D. Bennett wrote: > On Thu, Mar 13, 2025 at 02:43:09AM +0100, Benedikt Ziemons wrote: > > On Tue, 2025-03-11 at 21:53 -0400, Luiz Augusto von Dentz wrote: > > > Hi Chris, Sean, Hao, > > > > > > On Mon, Mar 10, 2025 at 5:24 PM Geraldo Nascimento > > > <geraldogabriel@gmail.com> 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://github.com/geoffreybennett/linux-fcp/issues/24 > > > > > > > > > > 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. > > > > > > > > > > Hello everyone, > > > > 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://github.com/geoffreybennett/scarlett-gen2/issues > > [ 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://github.com/geoffreybennett/scarlett-gen2/issues > > [ 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. > > > > Thank you, > > Ben > > Hi Ben, > > This bit sticks out to me: > > > [ 81.400030] lunar kernel: Bluetooth: hci0: Device setup in > > 20435397 usecs > > 20 seconds to initialise bluetooth, vs. 188ms when not doing the > reset: > > > [ 140.240011] lunar kernel: Bluetooth: hci0: Device setup in > > 188119 usecs > > Does it still take 20 seconds when the Scarlett is not plugged in at > boot time? Yes, it still takes 20 seconds without the Scarlett plugged in. Here are kernel messages about the mediatek device in this case: [ 6.620016] lunar kernel: Bluetooth: Core ver 2.22 [ 6.666695] lunar kernel: NET: Registered PF_BLUETOOTH protocol family [ 6.666756] lunar kernel: Bluetooth: HCI device and connection manager initialized [ 6.666770] lunar kernel: Bluetooth: HCI socket layer initialized [ 6.666784] lunar kernel: Bluetooth: L2CAP socket layer initialized [ 6.666794] lunar kernel: Bluetooth: SCO socket layer initialized [ 6.912392] lunar kernel: usbcore: registered new interface driver btusb [ 6.912402] lunar kernel: mt7921e 0000:0a:00.0: enabling device (0000 -> 0002) [ 6.912519] lunar kernel: mt7921e 0000:0a:00.0: ASIC revision: 79220010 [ 6.912627] lunar kernel: mt7921e 0000:0a:00.0: HW/SW Version: 0x8a108a10, Build Time: 20241106163228a [ 6.912739] lunar kernel: mt7921e 0000:0a:00.0: WM Firmware Version: ____000000, Build Time: 20241106163310 [ 6.912847] lunar kernel: Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20241106163512 [ 8.010016] lunar kernel: mt7921e 0000:0a:00.0 wlp10s0: renamed from wlan0 [ 12.723353] lunar kernel: usbcore: registered new interface driver snd-usb-audio [ 27.606693] lunar kernel: Bluetooth: hci0: Device setup in 20342576 usecs [ 27.606748] lunar kernel: Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. [ 27.883398] lunar kernel: Bluetooth: hci0: AOSP extensions version v1.00 [ 27.883466] lunar kernel: Bluetooth: hci0: AOSP quality report is supported > > I presume lsusb -t shows both devices on the same USB bus? Yes, indeed, they are both on bus 1. For the captures I also made sure that no other devices are on the same bus. I also just tried connecting the Scarlett to a different USB bus and cannot reproduce the original issue with this setup. > > Thanks, > Geoffrey.
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://github.com/geoffreybennett/linux-fcp/issues/24 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