drivers/mmc/host/sdhci-of-hlwd.c | 1 + drivers/mmc/host/sdhci.c | 8 +++++--- drivers/mmc/host/sdhci.h | 4 ++++ 3 files changed, 10 insertions(+), 3 deletions(-)
This patch series adds a new bit to quirks2 for disabling the bounce buffer. On some hardware, this is required for proper operation. An example of such hardware is the SDHCI controller of the Nintendo Wii's "Hollywood" chipset. Without this patch, the onboard Broadcom 4318 Wi-Fi fails to connect to any networks. Patch 1 introduces the new quirk bit. Patch 2 applies it to sdhci-of-hlwd. Michael Garofalo (2): mmc: sdhci: add quirk to disable the bounce buffer mmc: sdhci-of-hlwd: disable bounce buffer usage drivers/mmc/host/sdhci-of-hlwd.c | 1 + drivers/mmc/host/sdhci.c | 8 +++++--- drivers/mmc/host/sdhci.h | 4 ++++ 3 files changed, 10 insertions(+), 3 deletions(-) -- 2.51.0
On 06/10/2025 04:36, Michael Garofalo wrote:
> This patch series adds a new bit to quirks2 for disabling the bounce
> buffer. On some hardware, this is required for proper operation. An
> example of such hardware is the SDHCI controller of the Nintendo Wii's
> "Hollywood" chipset. Without this patch, the onboard Broadcom 4318
> Wi-Fi fails to connect to any networks.
The bounce buffer should not make any difference, so it is likely
a different problem that gets hidden when the bounce buffer is not
used.
Could you enable dynamic debug messages and show the messages
for the failing case?
Dynamic debug for mmc
---------------------
Kernel must be configured:
CONFIG_DYNAMIC_DEBUG=y
To enable mmc debug via sysfs:
echo 'file drivers/mmc/core/* +p' > /sys/kernel/debug/dynamic_debug/control
echo 'file drivers/mmc/host/* +p' > /sys/kernel/debug/dynamic_debug/control
To enable mmc debug via kernel command line:
dyndbg="file drivers/mmc/core/* +p;file drivers/mmc/host/* +p"
To disable mmc debug:
echo 'file drivers/mmc/core/* -p' > /sys/kernel/debug/dynamic_debug/control
echo 'file drivers/mmc/host/* -p' > /sys/kernel/debug/dynamic_debug/control
More general information in kernel documentation in kernel tree:
Documentation/admin-guide/dynamic-debug-howto.rst
https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html
>
> Patch 1 introduces the new quirk bit.
> Patch 2 applies it to sdhci-of-hlwd.
>
> Michael Garofalo (2):
> mmc: sdhci: add quirk to disable the bounce buffer
> mmc: sdhci-of-hlwd: disable bounce buffer usage
>
> drivers/mmc/host/sdhci-of-hlwd.c | 1 +
> drivers/mmc/host/sdhci.c | 8 +++++---
> drivers/mmc/host/sdhci.h | 4 ++++
> 3 files changed, 10 insertions(+), 3 deletions(-)
>
On 06/10/2025 10:35, Adrian Hunter wrote: > On 06/10/2025 04:36, Michael Garofalo wrote: >> This patch series adds a new bit to quirks2 for disabling the bounce >> buffer. On some hardware, this is required for proper operation. An >> example of such hardware is the SDHCI controller of the Nintendo Wii's >> "Hollywood" chipset. Without this patch, the onboard Broadcom 4318 >> Wi-Fi fails to connect to any networks. > > The bounce buffer should not make any difference, so it is likely > a different problem that gets hidden when the bounce buffer is not > used. > > Could you enable dynamic debug messages and show the messages > for the failing case? Actually will also need to see the messages in the "fixed" case to compare. > > Dynamic debug for mmc > --------------------- > > Kernel must be configured: > > CONFIG_DYNAMIC_DEBUG=y > > To enable mmc debug via sysfs: > > echo 'file drivers/mmc/core/* +p' > /sys/kernel/debug/dynamic_debug/control > echo 'file drivers/mmc/host/* +p' > /sys/kernel/debug/dynamic_debug/control > > To enable mmc debug via kernel command line: > > dyndbg="file drivers/mmc/core/* +p;file drivers/mmc/host/* +p" > > To disable mmc debug: > > echo 'file drivers/mmc/core/* -p' > /sys/kernel/debug/dynamic_debug/control > echo 'file drivers/mmc/host/* -p' > /sys/kernel/debug/dynamic_debug/control > > More general information in kernel documentation in kernel tree: > > Documentation/admin-guide/dynamic-debug-howto.rst > https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html > > >> >> Patch 1 introduces the new quirk bit. >> Patch 2 applies it to sdhci-of-hlwd. >> >> Michael Garofalo (2): >> mmc: sdhci: add quirk to disable the bounce buffer >> mmc: sdhci-of-hlwd: disable bounce buffer usage >> >> drivers/mmc/host/sdhci-of-hlwd.c | 1 + >> drivers/mmc/host/sdhci.c | 8 +++++--- >> drivers/mmc/host/sdhci.h | 4 ++++ >> 3 files changed, 10 insertions(+), 3 deletions(-) >> >
> On 06/10/2025 10:35, Adrian Hunter wrote: >> On 06/10/2025 04:36, Michael Garofalo wrote: >>> This patch series adds a new bit to quirks2 for disabling the bounce >>> buffer. On some hardware, this is required for proper operation. An >>> example of such hardware is the SDHCI controller of the Nintendo Wii's >>> "Hollywood" chipset. Without this patch, the onboard Broadcom 4318 >>> Wi-Fi fails to connect to any networks. >> >> The bounce buffer should not make any difference, so it is likely >> a different problem that gets hidden when the bounce buffer is not >> used. >> >>> Could you enable dynamic debug messages and show the messages >>> for the failing case? >> >>Actually will also need to see the messages in the "fixed" case >>to compare. I'm afraid I won't be able to provide those easily, at least not with the commands you've provided. Since the rootfs is _also_ running from SD, turning on full MMC logs like this produces an obscene amount of noise from the storage, unrelated to the SDIO wireless. It gets even worse with my original intention, which was to save the logs to SD Card, (since my USB Gecko serial console is rather flakey, and introduces corruption now and then), since it's now logging the writes of it's own logs in a permanent loop. If there's a way to narrow down the logs to specifically whatever portions you're interested in, and filter out the noise, I would happily provide it. (P.S. sorry about the blank message there, still working out how to deal with mailing lists) > >> >> Dynamic debug for mmc >> --------------------- >> >> Kernel must be configured: >> >> CONFIG_DYNAMIC_DEBUG=y >> >> To enable mmc debug via sysfs: >> >> echo 'file drivers/mmc/core/* +p' > /sys/kernel/debug/dynamic_debug/control >> echo 'file drivers/mmc/host/* +p' > /sys/kernel/debug/dynamic_debug/control >> >> To enable mmc debug via kernel command line: >> >> dyndbg="file drivers/mmc/core/* +p;file drivers/mmc/host/* +p" >> >> To disable mmc debug: >> >> echo 'file drivers/mmc/core/* -p' > /sys/kernel/debug/dynamic_debug/control >> echo 'file drivers/mmc/host/* -p' > /sys/kernel/debug/dynamic_debug/control >> >> More general information in kernel documentation in kernel tree: >> >> Documentation/admin-guide/dynamic-debug-howto.rst >> https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html >> >> >>> >>> Patch 1 introduces the new quirk bit. >>> Patch 2 applies it to sdhci-of-hlwd. >>> >>> Michael Garofalo (2): >>> mmc: sdhci: add quirk to disable the bounce buffer >>> mmc: sdhci-of-hlwd: disable bounce buffer usage >>> >>> drivers/mmc/host/sdhci-of-hlwd.c | 1 + >>> drivers/mmc/host/sdhci.c | 8 +++++--- >>> drivers/mmc/host/sdhci.h | 4 ++++ >>> 3 files changed, 10 insertions(+), 3 deletions(-) >>> >>
On 06/10/2025 12:28, Michael Garofalo wrote: >> On 06/10/2025 10:35, Adrian Hunter wrote: >>> On 06/10/2025 04:36, Michael Garofalo wrote: >>>> This patch series adds a new bit to quirks2 for disabling the bounce >>>> buffer. On some hardware, this is required for proper operation. An >>>> example of such hardware is the SDHCI controller of the Nintendo Wii's >>>> "Hollywood" chipset. Without this patch, the onboard Broadcom 4318 >>>> Wi-Fi fails to connect to any networks. >>> >>> The bounce buffer should not make any difference, so it is likely >>> a different problem that gets hidden when the bounce buffer is not >>> used. >>> >>>> Could you enable dynamic debug messages and show the messages >>>> for the failing case? >>> >>> Actually will also need to see the messages in the "fixed" case >>> to compare. > I'm afraid I won't be able to provide those easily, at least not with the > commands you've provided. Since the rootfs is _also_ running from SD, > turning on full MMC logs like this produces an obscene amount of noise > from the storage, unrelated to the SDIO wireless. It gets even worse with > my original intention, which was to save the logs to SD Card, (since my USB > Gecko serial console is rather flakey, and introduces corruption now and then), > since it's now logging the writes of it's own logs in a permanent loop. > If there's a way to narrow down the logs to specifically whatever portions > you're interested in, and filter out the noise, I would happily provide it. Are there any error messages?
> On 06/10/2025 12:28, Michael Garofalo wrote: >>> On 06/10/2025 10:35, Adrian Hunter wrote: >>>> On 06/10/2025 04:36, Michael Garofalo wrote: >>>>> This patch series adds a new bit to quirks2 for disabling the bounce >>>>> buffer. On some hardware, this is required for proper operation. An >>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's >>>>> "Hollywood" chipset. Without this patch, the onboard Broadcom 4318 >>>>> Wi-Fi fails to connect to any networks. >>>> >>>> The bounce buffer should not make any difference, so it is likely >>>> a different problem that gets hidden when the bounce buffer is not >>>> used. >>>> >>>>> Could you enable dynamic debug messages and show the messages >>>>> for the failing case? >>>> >>>> Actually will also need to see the messages in the "fixed" case >>>> to compare. >> I'm afraid I won't be able to provide those easily, at least not with the >> commands you've provided. Since the rootfs is _also_ running from SD, >> turning on full MMC logs like this produces an obscene amount of noise >> from the storage, unrelated to the SDIO wireless. It gets even worse with >> my original intention, which was to save the logs to SD Card, (since my USB >> Gecko serial console is rather flakey, and introduces corruption now and then), >> since it's now logging the writes of it's own logs in a permanent loop. >> If there's a way to narrow down the logs to specifically whatever portions >> you're interested in, and filter out the noise, I would happily provide it. > > Are there any error messages? If I drop the debug logs you mentioned so that I can actually see what's going on (they produce hundreds of lines / sec), here's what the Wi-Fi card actually reports with, vs without, MMC bounce buffers. With bounce buffers on, it takes several tries to load the firmware, and it can't authenticate to any network. I've tested and confirmed this effect on multiple consoles, across multiple reboots, on multiple Wi-Fi networks. Meanwhile with MMC bounce buffers off, it's much more functional. Logs with MMC bounce buffers *on* (without my patches): [ 168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318 [ 168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00 [ 168.508519] ssb: WARNING: Multiple ChipCommon found [ 168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1 [ 168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9) [ 168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7 [ 168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0 [ 168.719257] Broadcom 43xx driver loaded [ Features: S ] [ 168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2 [ 168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2 [ 168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2 [ 168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht' [ 176.156693] b43-phy0: Loading OpenSource firmware version 410.31754 [ 176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware [ 179.993008] b43-phy0: Loading OpenSource firmware version 410.31754 [ 179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware [ 186.940346] b43-phy0: Loading OpenSource firmware version 410.31754 [ 186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware [ 216.368668] b43-phy0: Loading OpenSource firmware version 410.31754 [ 216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware [ 221.750016] b43-phy0: Loading OpenSource firmware version 410.31754 [ 221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware [ 223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27) [ 223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3) [ 223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3) [ 223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3) [ 224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out [ 226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27) [ 226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3) [ 226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3) [ 226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3) [ 226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out [ 250.424168] b43-phy0: Loading OpenSource firmware version 410.31754 [ 250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware [ 255.806790] b43-phy0: Loading OpenSource firmware version 410.31754 [ 255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware [ 257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27) [ 257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3) [ 257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3) [ 257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3) [ 258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out [ 284.326415] b43-phy0: Loading OpenSource firmware version 410.31754 [ 284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware [ 289.836233] b43-phy0: Loading OpenSource firmware version 410.31754 [ 289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware [ 291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27) [ 291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3) [ 291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3) [ 291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3) [ 292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out <keeps trying and failing forever....> Logs with MMC bounce buffers *off* (with my patches): [ 383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318 [ 383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00 [ 383.986645] ssb: WARNING: Multiple ChipCommon found [ 383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1 [ 383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9) [ 383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7 [ 383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0 [ 384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2 [ 384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2 [ 384.086571] Broadcom 43xx driver loaded [ Features: S ] [ 384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2 [ 384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 395.097838] b43-phy0: Loading OpenSource firmware version 410.31754 [ 395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware [ 397.667851] b43-phy0: Loading OpenSource firmware version 410.31754 [ 397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware [ 403.940787] b43-phy0: Loading OpenSource firmware version 410.31754 [ 403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware [ 405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27) [ 405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3) [ 405.389013] wlan0: authenticated [ 405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3) [ 405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3) [ 405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3) [ 406.016481] wlan0: association with da:b3:70:18:7c:14 timed out [ 414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27) [ 414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3) [ 414.351544] wlan0: authenticated [ 414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3) [ 414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25) [ 414.431879] wlan0: associated [ 415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14 If there's anything further that would be useful here, let me know and I'd be happy to provide them.
On 08/10/2025 04:10, Michael Garofalo wrote:
>> On 06/10/2025 12:28, Michael Garofalo wrote:
>>>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>>>> buffer. On some hardware, this is required for proper operation. An
>>>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>>>> "Hollywood" chipset. Without this patch, the onboard Broadcom 4318
>>>>>> Wi-Fi fails to connect to any networks.
>>>>>
>>>>> The bounce buffer should not make any difference, so it is likely
>>>>> a different problem that gets hidden when the bounce buffer is not
>>>>> used.
>>>>>
>>>>>> Could you enable dynamic debug messages and show the messages
>>>>>> for the failing case?
>>>>>
>>>>> Actually will also need to see the messages in the "fixed" case
>>>>> to compare.
>>> I'm afraid I won't be able to provide those easily, at least not with the
>>> commands you've provided. Since the rootfs is _also_ running from SD,
>>> turning on full MMC logs like this produces an obscene amount of noise
>>> from the storage, unrelated to the SDIO wireless. It gets even worse with
>>> my original intention, which was to save the logs to SD Card, (since my USB
>>> Gecko serial console is rather flakey, and introduces corruption now and then),
>>> since it's now logging the writes of it's own logs in a permanent loop.
>>> If there's a way to narrow down the logs to specifically whatever portions
>>> you're interested in, and filter out the noise, I would happily provide it.
>>
>> Are there any error messages?
> If I drop the debug logs you mentioned so that I can actually see what's
> going on (they produce hundreds of lines / sec), here's what the Wi-Fi card
> actually reports with, vs without, MMC bounce buffers. With bounce buffers on,
> it takes several tries to load the firmware, and it can't authenticate to any
> network. I've tested and confirmed this effect on multiple consoles, across
> multiple reboots, on multiple Wi-Fi networks. Meanwhile with MMC bounce buffers
> off, it's much more functional.
>
> Logs with MMC bounce buffers *on* (without my patches):
> [ 168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> [ 168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00
> [ 168.508519] ssb: WARNING: Multiple ChipCommon found
> [ 168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
> [ 168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
> [ 168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
> [ 168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
> [ 168.719257] Broadcom 43xx driver loaded [ Features: S ]
> [ 168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
> [ 168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
> [ 168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
> [ 168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht'
> [ 176.156693] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 179.993008] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 186.940346] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 216.368668] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 221.750016] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [ 223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [ 223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
> [ 223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
> [ 224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out
> [ 226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [ 226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [ 226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
> [ 226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
> [ 226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out
> [ 250.424168] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 255.806790] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [ 257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [ 257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
> [ 257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
> [ 258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out
> [ 284.326415] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 289.836233] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [ 291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [ 291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
> [ 291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
> [ 292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out
> <keeps trying and failing forever....>
>
> Logs with MMC bounce buffers *off* (with my patches):
> [ 383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> [ 383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
> [ 383.986645] ssb: WARNING: Multiple ChipCommon found
> [ 383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
> [ 383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
> [ 383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
> [ 383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
> [ 384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
> [ 384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
> [ 384.086571] Broadcom 43xx driver loaded [ Features: S ]
> [ 384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
> [ 384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> [ 395.097838] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 397.667851] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 403.940787] b43-phy0: Loading OpenSource firmware version 410.31754
> [ 403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware
> [ 405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [ 405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [ 405.389013] wlan0: authenticated
> [ 405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
> [ 405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3)
> [ 405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3)
> [ 406.016481] wlan0: association with da:b3:70:18:7c:14 timed out
> [ 414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
> [ 414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
> [ 414.351544] wlan0: authenticated
> [ 414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
> [ 414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25)
> [ 414.431879] wlan0: associated
> [ 415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14
>
> If there's anything further that would be useful here, let me know and I'd be happy to provide them.
Seems the SDIO function driver b43-sdio does not print any error
messages. All the error paths in drivers/ssb/sdio.c print debug
messages instead.
I would suggest the following, which would limit messages to
host mmc1 which is what is shown in message "b43-sdio mmc1:0001:1:
Chip ID 14e4:4318"
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 860378bea557..2719b21783ad 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -169,33 +169,33 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
* - The card was removed (...so just complete everything no matter
* if there are errors or retries)
*/
- if (!err || !cmd->retries || mmc_card_removed(host->card)) {
+ if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
mmc_should_fail_request(host, mrq);
if (!host->ongoing_mrq)
led_trigger_event(host->led, LED_OFF);
if (mrq->sbc) {
- pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
+ pr_info("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
mmc_hostname(host), mrq->sbc->opcode,
mrq->sbc->error,
mrq->sbc->resp[0], mrq->sbc->resp[1],
mrq->sbc->resp[2], mrq->sbc->resp[3]);
}
- pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
+ pr_info("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
mmc_hostname(host), cmd->opcode, err,
cmd->resp[0], cmd->resp[1],
cmd->resp[2], cmd->resp[3]);
if (mrq->data) {
- pr_debug("%s: %d bytes transferred: %d\n",
+ pr_info("%s: %d bytes transferred: %d\n",
mmc_hostname(host),
mrq->data->bytes_xfered, mrq->data->error);
}
if (mrq->stop) {
- pr_debug("%s: (CMD%u): %d: %08x %08x %08x %08x\n",
+ pr_info("%s: (CMD%u): %d: %08x %08x %08x %08x\n",
mmc_hostname(host), mrq->stop->opcode,
mrq->stop->error,
mrq->stop->resp[0], mrq->stop->resp[1],
> On 08/10/2025 04:10, Michael Garofalo wrote:
>>> On 06/10/2025 12:28, Michael Garofalo wrote:
>>>>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>>>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>>>>> buffer. On some hardware, this is required for proper operation. An
>>>>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>>>>> "Hollywood" chipset. Without this patch, the onboard Broadcom 4318
>>>>>>> Wi-Fi fails to connect to any networks.
>>>>>>
>>>>>> The bounce buffer should not make any difference, so it is likely
>>>>>> a different problem that gets hidden when the bounce buffer is not
>>>>>> used.
>>>>>>
>>>>>>> Could you enable dynamic debug messages and show the messages
>>>>>>> for the failing case?
>>>>>>
>>>>>> Actually will also need to see the messages in the "fixed" case
>>>>>> to compare.
>>>> I'm afraid I won't be able to provide those easily, at least not with the
>>>> commands you've provided. Since the rootfs is _also_ running from SD,
>>>> turning on full MMC logs like this produces an obscene amount of noise
>>>> from the storage, unrelated to the SDIO wireless. It gets even worse with
>>>> my original intention, which was to save the logs to SD Card, (since my USB
>>>> Gecko serial console is rather flakey, and introduces corruption now and then),
>>>> since it's now logging the writes of it's own logs in a permanent loop.
>>>> If there's a way to narrow down the logs to specifically whatever portions
>>>> you're interested in, and filter out the noise, I would happily provide it.
>>>
>>> Are there any error messages?
>> If I drop the debug logs you mentioned so that I can actually see what's
>> going on (they produce hundreds of lines / sec), here's what the Wi-Fi card
>> actually reports with, vs without, MMC bounce buffers. With bounce buffers on,
>> it takes several tries to load the firmware, and it can't authenticate to any
>> network. I've tested and confirmed this effect on multiple consoles, across
>> multiple reboots, on multiple Wi-Fi networks. Meanwhile with MMC bounce buffers
>> off, it's much more functional.
>>
>> Logs with MMC bounce buffers *on* (without my patches):
>> [ 168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>> [ 168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00
>> [ 168.508519] ssb: WARNING: Multiple ChipCommon found
>> [ 168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>> [ 168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>> [ 168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>> [ 168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>> [ 168.719257] Broadcom 43xx driver loaded [ Features: S ]
>> [ 168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>> [ 168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>> [ 168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>> [ 168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht'
>> [ 176.156693] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 179.993008] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 186.940346] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 216.368668] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 221.750016] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [ 223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [ 223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>> [ 223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>> [ 224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out
>> [ 226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [ 226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [ 226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>> [ 226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>> [ 226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out
>> [ 250.424168] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 255.806790] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [ 257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [ 257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>> [ 257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>> [ 258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out
>> [ 284.326415] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 289.836233] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [ 291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [ 291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>> [ 291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>> [ 292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out
>> <keeps trying and failing forever....>
>>
>> Logs with MMC bounce buffers *off* (with my patches):
>> [ 383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>> [ 383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
>> [ 383.986645] ssb: WARNING: Multiple ChipCommon found
>> [ 383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>> [ 383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>> [ 383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>> [ 383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>> [ 384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>> [ 384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>> [ 384.086571] Broadcom 43xx driver loaded [ Features: S ]
>> [ 384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>> [ 384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>> [ 395.097838] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 397.667851] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 403.940787] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ 403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ 405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [ 405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [ 405.389013] wlan0: authenticated
>> [ 405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>> [ 405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3)
>> [ 405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3)
>> [ 406.016481] wlan0: association with da:b3:70:18:7c:14 timed out
>> [ 414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>> [ 414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>> [ 414.351544] wlan0: authenticated
>> [ 414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>> [ 414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25)
>> [ 414.431879] wlan0: associated
>> [ 415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14
>>
>> If there's anything further that would be useful here, let me know and I'd be happy to provide them.
>
> Seems the SDIO function driver b43-sdio does not print any error
> messages. All the error paths in drivers/ssb/sdio.c print debug
> messages instead.
>
> I would suggest the following, which would limit messages to
> host mmc1 which is what is shown in message "b43-sdio mmc1:0001:1:
> Chip ID 14e4:4318"
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 860378bea557..2719b21783ad 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -169,33 +169,33 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
> * - The card was removed (...so just complete everything no matter
> * if there are errors or retries)
> */
> - if (!err || !cmd->retries || mmc_card_removed(host->card)) {
> + if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
> mmc_should_fail_request(host, mrq);
>
> if (!host->ongoing_mrq)
> led_trigger_event(host->led, LED_OFF);
>
> if (mrq->sbc) {
> - pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
> + pr_info("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
> mmc_hostname(host), mrq->sbc->opcode,
> mrq->sbc->error,
> mrq->sbc->resp[0], mrq->sbc->resp[1],
> mrq->sbc->resp[2], mrq->sbc->resp[3]);
> }
>
> - pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
> + pr_info("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
> mmc_hostname(host), cmd->opcode, err,
> cmd->resp[0], cmd->resp[1],
> cmd->resp[2], cmd->resp[3]);
>
> if (mrq->data) {
> - pr_debug("%s: %d bytes transferred: %d\n",
> + pr_info("%s: %d bytes transferred: %d\n",
> mmc_hostname(host),
> mrq->data->bytes_xfered, mrq->data->error);
> }
>
> if (mrq->stop) {
> - pr_debug("%s: (CMD%u): %d: %08x %08x %08x %08x\n",
> + pr_info("%s: (CMD%u): %d: %08x %08x %08x %08x\n",
> mmc_hostname(host), mrq->stop->opcode,
> mrq->stop->error,
> mrq->stop->resp[0], mrq->stop->resp[1],
With these patches, I still get copious amounts of spam, but at least relevant
to the wifi card now.
Here's a hopefully useful snippet (it's just a lot of these, from what I could see),
from with my patches:
[ 154.177276] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 154.177297] mmc1: 4 bytes transferred: 0
<...>
[ 186.707195] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 186.707217] mmc1: 20 bytes transferred: 0
[ 186.707358] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 186.707382] mmc1: 384 bytes transferred: 0
[ 186.707477] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 186.707498] mmc1: 24 bytes transferred: 0
And the one from without is very similar, except I noticed this pattern:
[ 85.942269] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 85.942299] mmc1: 4 bytes transferred: 0
[ 85.942523] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 85.942555] mmc1: 4 bytes transferred: 0
[ 85.944548] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 85.944581] mmc1: 2 bytes transferred: 0
[ 85.944777] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 85.945160] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 85.945187] mmc1: 2 bytes transferred: 0
... occasionally, some of the requests don't have an "[x] bytes transferred: 0".
Hopefully these help. I can get a capture of the entire log spam and
put it on on pastebin or something, if that would be more useful.
On 11/10/2025 00:16, Michael Garofalo wrote:
>> On 08/10/2025 04:10, Michael Garofalo wrote:
>>>> On 06/10/2025 12:28, Michael Garofalo wrote:
>>>>>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>>>>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>>>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>>>>>> buffer. On some hardware, this is required for proper operation. An
>>>>>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>>>>>> "Hollywood" chipset. Without this patch, the onboard Broadcom 4318
>>>>>>>> Wi-Fi fails to connect to any networks.
>>>>>>>
>>>>>>> The bounce buffer should not make any difference, so it is likely
>>>>>>> a different problem that gets hidden when the bounce buffer is not
>>>>>>> used.
>>>>>>>
>>>>>>>> Could you enable dynamic debug messages and show the messages
>>>>>>>> for the failing case?
>>>>>>>
>>>>>>> Actually will also need to see the messages in the "fixed" case
>>>>>>> to compare.
>>>>> I'm afraid I won't be able to provide those easily, at least not with the
>>>>> commands you've provided. Since the rootfs is _also_ running from SD,
>>>>> turning on full MMC logs like this produces an obscene amount of noise
>>>>> from the storage, unrelated to the SDIO wireless. It gets even worse with
>>>>> my original intention, which was to save the logs to SD Card, (since my USB
>>>>> Gecko serial console is rather flakey, and introduces corruption now and then),
>>>>> since it's now logging the writes of it's own logs in a permanent loop.
>>>>> If there's a way to narrow down the logs to specifically whatever portions
>>>>> you're interested in, and filter out the noise, I would happily provide it.
>>>>
>>>> Are there any error messages?
>>> If I drop the debug logs you mentioned so that I can actually see what's
>>> going on (they produce hundreds of lines / sec), here's what the Wi-Fi card
>>> actually reports with, vs without, MMC bounce buffers. With bounce buffers on,
>>> it takes several tries to load the firmware, and it can't authenticate to any
>>> network. I've tested and confirmed this effect on multiple consoles, across
>>> multiple reboots, on multiple Wi-Fi networks. Meanwhile with MMC bounce buffers
>>> off, it's much more functional.
>>>
>>> Logs with MMC bounce buffers *on* (without my patches):
>>> [ 168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>> [ 168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00
>>> [ 168.508519] ssb: WARNING: Multiple ChipCommon found
>>> [ 168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>>> [ 168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>>> [ 168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>>> [ 168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>>> [ 168.719257] Broadcom 43xx driver loaded [ Features: S ]
>>> [ 168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>> [ 168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>> [ 168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>>> [ 168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht'
>>> [ 176.156693] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 179.993008] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 186.940346] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 216.368668] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 221.750016] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [ 223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [ 223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>> [ 223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>> [ 224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>> [ 226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [ 226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [ 226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>> [ 226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>> [ 226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>> [ 250.424168] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 255.806790] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [ 257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [ 257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>> [ 257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>> [ 258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>> [ 284.326415] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 289.836233] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [ 291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [ 291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>> [ 291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>> [ 292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>> <keeps trying and failing forever....>
>>>
>>> Logs with MMC bounce buffers *off* (with my patches):
>>> [ 383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>> [ 383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
>>> [ 383.986645] ssb: WARNING: Multiple ChipCommon found
>>> [ 383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>>> [ 383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>>> [ 383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>>> [ 383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>>> [ 384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>> [ 384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>> [ 384.086571] Broadcom 43xx driver loaded [ Features: S ]
>>> [ 384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>>> [ 384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>>> [ 395.097838] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 397.667851] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 403.940787] b43-phy0: Loading OpenSource firmware version 410.31754
>>> [ 403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware
>>> [ 405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [ 405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [ 405.389013] wlan0: authenticated
>>> [ 405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>>> [ 405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3)
>>> [ 405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3)
>>> [ 406.016481] wlan0: association with da:b3:70:18:7c:14 timed out
>>> [ 414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>> [ 414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>> [ 414.351544] wlan0: authenticated
>>> [ 414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>>> [ 414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25)
>>> [ 414.431879] wlan0: associated
>>> [ 415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14
>>>
>>> If there's anything further that would be useful here, let me know and I'd be happy to provide them.
>>
>> Seems the SDIO function driver b43-sdio does not print any error
>> messages. All the error paths in drivers/ssb/sdio.c print debug
>> messages instead.
>>
>> I would suggest the following, which would limit messages to
>> host mmc1 which is what is shown in message "b43-sdio mmc1:0001:1:
>> Chip ID 14e4:4318"
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index 860378bea557..2719b21783ad 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -169,33 +169,33 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
>> * - The card was removed (...so just complete everything no matter
>> * if there are errors or retries)
>> */
>> - if (!err || !cmd->retries || mmc_card_removed(host->card)) {
>> + if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
>> mmc_should_fail_request(host, mrq);
>>
>> if (!host->ongoing_mrq)
>> led_trigger_event(host->led, LED_OFF);
>>
>> if (mrq->sbc) {
>> - pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>> + pr_info("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>> mmc_hostname(host), mrq->sbc->opcode,
>> mrq->sbc->error,
>> mrq->sbc->resp[0], mrq->sbc->resp[1],
>> mrq->sbc->resp[2], mrq->sbc->resp[3]);
>> }
>>
>> - pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>> + pr_info("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>> mmc_hostname(host), cmd->opcode, err,
>> cmd->resp[0], cmd->resp[1],
>> cmd->resp[2], cmd->resp[3]);
>>
>> if (mrq->data) {
>> - pr_debug("%s: %d bytes transferred: %d\n",
>> + pr_info("%s: %d bytes transferred: %d\n",
>> mmc_hostname(host),
>> mrq->data->bytes_xfered, mrq->data->error);
>> }
>>
>> if (mrq->stop) {
>> - pr_debug("%s: (CMD%u): %d: %08x %08x %08x %08x\n",
>> + pr_info("%s: (CMD%u): %d: %08x %08x %08x %08x\n",
>> mmc_hostname(host), mrq->stop->opcode,
>> mrq->stop->error,
>> mrq->stop->resp[0], mrq->stop->resp[1],
>
> With these patches, I still get copious amounts of spam, but at least relevant
> to the wifi card now.
> Here's a hopefully useful snippet (it's just a lot of these, from what I could see),
> from with my patches:
>
> [ 154.177276] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [ 154.177297] mmc1: 4 bytes transferred: 0
> <...>
> [ 186.707195] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [ 186.707217] mmc1: 20 bytes transferred: 0
> [ 186.707358] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [ 186.707382] mmc1: 384 bytes transferred: 0
> [ 186.707477] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [ 186.707498] mmc1: 24 bytes transferred: 0
>
> And the one from without is very similar, except I noticed this pattern:
> [ 85.942269] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [ 85.942299] mmc1: 4 bytes transferred: 0
> [ 85.942523] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [ 85.942555] mmc1: 4 bytes transferred: 0
> [ 85.944548] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [ 85.944581] mmc1: 2 bytes transferred: 0
> [ 85.944777] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [ 85.945160] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
> [ 85.945187] mmc1: 2 bytes transferred: 0
> ... occasionally, some of the requests don't have an "[x] bytes transferred: 0".
>
> Hopefully these help. I can get a capture of the entire log spam and
> put it on on pastebin or something, if that would be more useful.
Need to know if there are any errors. In "[x] bytes transferred: 0"
messages, the "0" is the error code i.e. no error. So you might be able
to find errors like:
dmesg | grep 'bytes transferred' | grep -v 'bytes transferred: 0'
Also the debug patch could be tweaked to show errors only:
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2719b21783ad..7b18fe6d5738 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -169,7 +169,7 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
* - The card was removed (...so just complete everything no matter
* if there are errors or retries)
*/
- if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
+ if (host->index == 1 && (err || (mrq->data && mrq->data->error))) {
mmc_should_fail_request(host, mrq);
if (!host->ongoing_mrq)
> On 11/10/2025 00:16, Michael Garofalo wrote:
>>> On 08/10/2025 04:10, Michael Garofalo wrote:
>>>>> On 06/10/2025 12:28, Michael Garofalo wrote:
>>>>>>> On 06/10/2025 10:35, Adrian Hunter wrote:
>>>>>>>> On 06/10/2025 04:36, Michael Garofalo wrote:
>>>>>>>>> This patch series adds a new bit to quirks2 for disabling the bounce
>>>>>>>>> buffer. On some hardware, this is required for proper operation. An
>>>>>>>>> example of such hardware is the SDHCI controller of the Nintendo Wii's
>>>>>>>>> "Hollywood" chipset. Without this patch, the onboard Broadcom 4318
>>>>>>>>> Wi-Fi fails to connect to any networks.
>>>>>>>>
>>>>>>>> The bounce buffer should not make any difference, so it is likely
>>>>>>>> a different problem that gets hidden when the bounce buffer is not
>>>>>>>> used.
>>>>>>>>
>>>>>>>>> Could you enable dynamic debug messages and show the messages
>>>>>>>>> for the failing case?
>>>>>>>>
>>>>>>>> Actually will also need to see the messages in the "fixed" case
>>>>>>>> to compare.
>>>>>> I'm afraid I won't be able to provide those easily, at least not with the
>>>>>> commands you've provided. Since the rootfs is _also_ running from SD,
>>>>>> turning on full MMC logs like this produces an obscene amount of noise
>>>>>> from the storage, unrelated to the SDIO wireless. It gets even worse with
>>>>>> my original intention, which was to save the logs to SD Card, (since my USB
>>>>>> Gecko serial console is rather flakey, and introduces corruption now and then),
>>>>>> since it's now logging the writes of it's own logs in a permanent loop.
>>>>>> If there's a way to narrow down the logs to specifically whatever portions
>>>>>> you're interested in, and filter out the noise, I would happily provide it.
>>>>>
>>>>> Are there any error messages?
>>>> If I drop the debug logs you mentioned so that I can actually see what's
>>>> going on (they produce hundreds of lines / sec), here's what the Wi-Fi card
>>>> actually reports with, vs without, MMC bounce buffers. With bounce buffers on,
>>>> it takes several tries to load the firmware, and it can't authenticate to any
>>>> network. I've tested and confirmed this effect on multiple consoles, across
>>>> multiple reboots, on multiple Wi-Fi networks. Meanwhile with MMC bounce buffers
>>>> off, it's much more functional.
>>>>
>>>> Logs with MMC bounce buffers *on* (without my patches):
>>>> [ 168.492687] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>>> [ 168.493516] ssb: Found chip with id 0x4710, rev 0x00 an package 0x00
>>>> [ 168.508519] ssb: WARNING: Multiple ChipCommon found
>>>> [ 168.510597] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>>>> [ 168.510886] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>>>> [ 168.530151] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>>>> [ 168.538447] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>>>> [ 168.719257] Broadcom 43xx driver loaded [ Features: S ]
>>>> [ 168.722231] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>> [ 168.724613] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>> [ 168.740666] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>>>> [ 168.762630] ieee80211 phy0: Slected rate control algorithm 'minstrel_ht'
>>>> [ 176.156693] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 176.157159] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 179.993008] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 179.994373] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 186.940346] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 186.942559] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 216.368668] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 216.369135] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 221.750016] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 221.757700] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 223.437731] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [ 223.437764] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [ 223.648472] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>> [ 223.859770] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>> [ 224.064469] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>> [ 226.045361] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [ 226.045393] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [ 226.248488] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>> [ 226.462378] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>> [ 226.664487] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>> [ 250.424168] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 250.425629] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 255.806790] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 255.807256] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 257.467380] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [ 257.467414] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [ 257.672475] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>> [ 257.880474] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>> [ 258.093974] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>> [ 284.326415] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 284.326922] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 289.836233] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 289.837612] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 291.528250] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [ 291.528283] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [ 291.736473] wlan0: send auth to da:b3:70:18:7c:14 (try 2/3)
>>>> [ 291.944482] wlan0: send auth to da:b3:70:18:7c:14 (try 3/3)
>>>> [ 292.152470] wlan0: authentication with da:b3:70:18:7c:14 timed out
>>>> <keeps trying and failing forever....>
>>>>
>>>> Logs with MMC bounce buffers *off* (with my patches):
>>>> [ 383.974268] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>>> [ 383.975824] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
>>>> [ 383.986645] ssb: WARNING: Multiple ChipCommon found
>>>> [ 383.987414] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
>>>> [ 383.987744] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
>>>> [ 383.995898] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>>>> [ 383.996249] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
>>>> [ 384.077562] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>> [ 384.077687] b43 ssb0:0: Direct firmware load for b43/ucode5.fw failed with error -2
>>>> [ 384.086571] Broadcom 43xx driver loaded [ Features: S ]
>>>> [ 384.144620] b43 ssb0:0: Direct firmware load for b43-open/pcm5.fw failed with error -2
>>>> [ 384.190831] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>>>> [ 395.097838] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 395.098158] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 397.667851] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 397.668171] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 403.940787] b43-phy0: Loading OpenSource firmware version 410.31754
>>>> [ 403.941110] b43-phy0: Hardware crypto acceleration not supported by firmware
>>>> [ 405.366065] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [ 405.366095] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [ 405.389013] wlan0: authenticated
>>>> [ 405.392814] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>>>> [ 405.600498] wlan0: associate with da:b3:70:18:7c:14 (try 2/3)
>>>> [ 405.808479] wlan0: associate with da:b3:70:18:7c:14 (try 3/3)
>>>> [ 406.016481] wlan0: association with da:b3:70:18:7c:14 timed out
>>>> [ 414.301216] wlan0: authenticate with da:b3:70:18:7c:14 (local address=00:1c:be:ab:73:27)
>>>> [ 414.301245] wlan0: send auth to da:b3:70:18:7c:14 (try 1/3)
>>>> [ 414.351544] wlan0: authenticated
>>>> [ 414.403769] wlan0: associate with da:b3:70:18:7c:14 (try 1/3)
>>>> [ 414.422775] wlan0: RX AssocResp from da:b3:70:18:7c:14 (capab=0x1411 status=0 aid=25)
>>>> [ 414.431879] wlan0: associated
>>>> [ 415.272393] wlan0: Limiting TX power to 36 (36 - 0) dBm as advertised by da:b3:70:18:7c:14
>>>>
>>>> If there's anything further that would be useful here, let me know and I'd be happy to provide them.
>>>
>>> Seems the SDIO function driver b43-sdio does not print any error
>>> messages. All the error paths in drivers/ssb/sdio.c print debug
>>> messages instead.
>>>
>>> I would suggest the following, which would limit messages to
>>> host mmc1 which is what is shown in message "b43-sdio mmc1:0001:1:
>>> Chip ID 14e4:4318"
>>>
>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>> index 860378bea557..2719b21783ad 100644
>>> --- a/drivers/mmc/core/core.c
>>> +++ b/drivers/mmc/core/core.c
>>> @@ -169,33 +169,33 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
>>> * - The card was removed (...so just complete everything no matter
>>> * if there are errors or retries)
>>> */
>>> - if (!err || !cmd->retries || mmc_card_removed(host->card)) {
>>> + if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
>>> mmc_should_fail_request(host, mrq);
>>>
>>> if (!host->ongoing_mrq)
>>> led_trigger_event(host->led, LED_OFF);
>>>
>>> if (mrq->sbc) {
>>> - pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>>> + pr_info("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
>>> mmc_hostname(host), mrq->sbc->opcode,
>>> mrq->sbc->error,
>>> mrq->sbc->resp[0], mrq->sbc->resp[1],
>>> mrq->sbc->resp[2], mrq->sbc->resp[3]);
>>> }
>>>
>>> - pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>>> + pr_info("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
>>> mmc_hostname(host), cmd->opcode, err,
>>> cmd->resp[0], cmd->resp[1],
>>> cmd->resp[2], cmd->resp[3]);
>>>
>>> if (mrq->data) {
>>> - pr_debug("%s: %d bytes transferred: %d\n",
>>> + pr_info("%s: %d bytes transferred: %d\n",
>>> mmc_hostname(host),
>>> mrq->data->bytes_xfered, mrq->data->error);
>>> }
>>>
>>> if (mrq->stop) {
>>> - pr_debug("%s: (CMD%u): %d: %08x %08x %08x %08x\n",
>>> + pr_info("%s: (CMD%u): %d: %08x %08x %08x %08x\n",
>>> mmc_hostname(host), mrq->stop->opcode,
>>> mrq->stop->error,
>>> mrq->stop->resp[0], mrq->stop->resp[1],
>>
>> With these patches, I still get copious amounts of spam, but at least relevant
>> to the wifi card now.
>> Here's a hopefully useful snippet (it's just a lot of these, from what I could see),
>> from with my patches:
>>
>> [ 154.177276] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [ 154.177297] mmc1: 4 bytes transferred: 0
>> <...>
>> [ 186.707195] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [ 186.707217] mmc1: 20 bytes transferred: 0
>> [ 186.707358] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [ 186.707382] mmc1: 384 bytes transferred: 0
>> [ 186.707477] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [ 186.707498] mmc1: 24 bytes transferred: 0
>>
>> And the one from without is very similar, except I noticed this pattern:
>> [ 85.942269] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [ 85.942299] mmc1: 4 bytes transferred: 0
>> [ 85.942523] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [ 85.942555] mmc1: 4 bytes transferred: 0
>> [ 85.944548] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [ 85.944581] mmc1: 2 bytes transferred: 0
>> [ 85.944777] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [ 85.945160] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
>> [ 85.945187] mmc1: 2 bytes transferred: 0
>> ... occasionally, some of the requests don't have an "[x] bytes transferred: 0".
>>
>> Hopefully these help. I can get a capture of the entire log spam and
>> put it on on pastebin or something, if that would be more useful.
>
> Need to know if there are any errors. In "[x] bytes transferred: 0"
> messages, the "0" is the error code i.e. no error. So you might be able
> to find errors like:
>
> dmesg | grep 'bytes transferred' | grep -v 'bytes transferred: 0'
>
> Also the debug patch could be tweaked to show errors only:
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 2719b21783ad..7b18fe6d5738 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -169,7 +169,7 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
> * - The card was removed (...so just complete everything no matter
> * if there are errors or retries)
> */
> - if (host->index == 1 && (!err || !cmd->retries || mmc_card_removed(host->card))) {
> + if (host->index == 1 && (err || (mrq->data && mrq->data->error))) {
> mmc_should_fail_request(host, mrq);
>
> if (!host->ongoing_mrq)
These patches were mildly revealing, I see this near the start of the logs:
[ 32.222988] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[ 32.224789] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00
[ 32.227574] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 32.227834] mmc1: 0 bytes transferred: -84
[ 32.229615] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 32.229876] mmc1: 0 bytes transferred: -84
[ 32.230400] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 32.230659] mmc1: 0 bytes transferred: -84
[ 32.231173] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 32.231476] mmc1: 0 bytes transferred: -84
[ 32.233287] ssb: WARNING: Multiple ChipCommon found
[ 32.234489] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
[ 32.238533] b43-phy0: Broadcom 4710 WLAN found (core revision 9)
[ 32.264908] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
[ 32.272565] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0
This occurs either with, or without, my patches. However, no further
errors were logged. Despite the lack of reported errors, the
functional behavior remained the same as I described earlier.
© 2016 - 2025 Red Hat, Inc.