Resent due to subject error. Apologies, Hante :)
Hi Folks,
9fe929aaace6 brcmfmac: add firmware feature detection for gscan feature
Completely breaks 43430a1 support.
This was tested on top of my last patchset - but the same occurs on top
of vanilla 4.13-rc1
[ 15.703014] [1 ] core 0x800:49 base 0x18000000 wrap 0x18100000
[ 15.703025] [2 ] core 0x812:39 base 0x18001000 wrap 0x18101000
[ 15.703036] [3 ] core 0x829:21 base 0x18002000 wrap 0x18102000
[ 15.703044] [4 ] core 0x82a:9 base 0x18003000 wrap 0x18103000
[ 15.703052] [5 ] core 0x80e:22 base 0x18004000 wrap 0x18104000
[ 15.703059] [6 ] core 0x135:0 base 0x00000000 wrap 0x18105000
[ 15.703067] [7 ] core 0x240:0 base 0x00000000 wrap 0x18106000
[ 15.703070] Enter
[ 15.735280] RAM: base=0x0 size=524288 (0x80000) sr=65536 (0x10000)
[ 15.735293] Found BCM43430, AXI backplane, rev=1
[ 15.735461] ccrev=49, pmurev=24, pmucaps=0x39d25f18
[ 15.904051] Enter
[ 15.974045] Enter
[ 15.984378] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
Aug 29 2016 20:48:16 version 7.45.41.26 (r640327) FWID 01-4527cfab
[ 16.009363] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data
content: 0x40012
...
[ 18.566406] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
...
[ 21.126419] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[ 23.686371] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
...
[ 26.246357] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[ 28.806347] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[ 31.366355] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[ 33.926319] brcmfmac: brcmf_proto_bcdc_query_dcmd:
brcmf_proto_bcdc_msg failed w/status -110
[ 36.486448] brcmfmac: brcmf_proto_bcdc_query_dcmd:
brcmf_proto_bcdc_msg failed w/status -110
[ 36.497332] brcmfmac: brcmf_cfg80211_attach: Failed to get D11
version (-110)
[ 36.504059] brcmfmac: brcmf_bus_started: failed: -12
[ 36.517686] brcmfmac: brcmf_sdio_firmware_callback: dongle is not
responding
[ 36.586256] Enter
-Ian
On 17/07/17 20:53, Arend van Spriel wrote:
>> 2) The firmware is failing when asked to handle the new requiests, and
>> is going to la-la land.
> taken a wrong turn straight into la-la land.
Doh!
>> I have version wl0: Aug 29 2016 20:48:16 version 7.45.41.26 (r640327)
>> FWID 01-4527cfab
> Not so much newer firmware, but I used a different chip when
> implementing the multi-scheduled scan patches. I tried some other
> devices, but not the bcm4343{0,8}. Now as far as I can see over here the
> brcmfmac43430-sdio.bin is not built with gscan support so it should just
> return firmware errorcode, ie. -23. So it would be interesting to see
> what firmware has to say. Can you load the driver with
> ignore_probe_fail=1 and dump the forensics file in debugfs.
I don't appear to get anything useful in debugfs. Where should I be looking?
-Ian
On 17-07-17 22:13, Ian Molton wrote:
> On 17/07/17 20:53, Arend van Spriel wrote:
>>> 2) The firmware is failing when asked to handle the new requiests, and
>>> is going to la-la land.
>> taken a wrong turn straight into la-la land.
>
> Doh!
>
>>> I have version wl0: Aug 29 2016 20:48:16 version 7.45.41.26 (r640327)
>>> FWID 01-4527cfab
>> Not so much newer firmware, but I used a different chip when
>> implementing the multi-scheduled scan patches. I tried some other
>> devices, but not the bcm4343{0,8}. Now as far as I can see over here the
>> brcmfmac43430-sdio.bin is not built with gscan support so it should just
>> return firmware errorcode, ie. -23. So it would be interesting to see
>> what firmware has to say. Can you load the driver with
>> ignore_probe_fail=1 and dump the forensics file in debugfs.
>
> I don't appear to get anything useful in debugfs. Where should I be looking?
In <debugfs_mountpoint>/brcmfmac/*/forensics, but you have to load the
driver with modules parameter 'ignore_probe_fail=1' to avoid the driver
remove tearing down all debugfs stuff.
On 18-07-17 00:10, Ian Molton wrote:
> Hi Arend,
>
> This is all there is in the forensics file, hope its of some use.
>
> # cat /sys/kernel/debug/brcmfmac/mmc1\:0001\:1/forensics
> Enter
> hndarm_armr addr: 0x18003000, cr4_idx: 0
> 000000.000
> RTE (SDIO-CDC) 7.45.41.26 (r640327) on BCM43430 r1 @ 37.4/81.0/81.0MHz
> 000000.001 sdpcmdcdc0: Broadcom SDPCMD CDC driver
> 000000.005 reclaim section 0: Returned 47716 bytes to the heap
> 000000.007 wlc_bmac_info_init: host_enab 1
> 000000.025 wl0: Broadcom BCM43430 802.11 Wireless Controller 7.45.41.26
> (r640327)
> 000000.026 TCAM: 256 used: 179 exceed:0
> 000000.027 reclaim section 1: Returned 81268 bytes to the heap
You probably guessed it, but this does not show anything useful. The
behavior suggested a firmware crash, but that does not seem to be
happening. Maybe it is the SDIO core driver on the firmware side which
is in la-la land.
Regards,
Arend
On 17-07-17 22:41, Ian Molton wrote:
> On 17/07/17 21:36, Arend van Spriel wrote:
>
>> In <debugfs_mountpoint>/brcmfmac/*/forensics, but you have to load the
>> driver with modules parameter 'ignore_probe_fail=1' to avoid the driver
>> remove tearing down all debugfs stuff.
>
> modinfo shows:
>
> parm: txglomsz:Maximum tx packet chain size [SDIO] (int)
> parm: debug:Level of debug output (int)
> parm: p2pon:Enable legacy p2p management functionality (int)
> parm: feature_disable:Disable features (int)
> parm: alternative_fw_path:Alternative firmware path (string)
> parm: fcmode:Mode of firmware signalled flow control (int)
> parm: roamoff:Do not use internal roaming engine (int)
>
Seems you did not build with CONFIG_BRCMDBG?
common.c:
#ifdef DEBUG
/* always succeed brcmf_bus_started() */
static int brcmf_ignore_probe_fail;
module_param_named(ignore_probe_fail, brcmf_ignore_probe_fail, int, 0);
MODULE_PARM_DESC(ignore_probe_fail, "always succeed probe for debugging");
#endif
Regards,
Arend
On 17/07/17 21:36, Arend van Spriel wrote:
> In <debugfs_mountpoint>/brcmfmac/*/forensics, but you have to load the
> driver with modules parameter 'ignore_probe_fail=1' to avoid the driver
> remove tearing down all debugfs stuff.
modinfo shows:
parm: txglomsz:Maximum tx packet chain size [SDIO] (int)
parm: debug:Level of debug output (int)
parm: p2pon:Enable legacy p2p management functionality (int)
parm: feature_disable:Disable features (int)
parm: alternative_fw_path:Alternative firmware path (string)
parm: fcmode:Mode of firmware signalled flow control (int)
parm: roamoff:Do not use internal roaming engine (int)
On 17/07/17 18:50, Ian Molton wrote:
> Resent due to subject error. Apologies, Hante :)
>
> Hi Folks,
>
> 9fe929aaace6 brcmfmac: add firmware feature detection for gscan feature
>
> Completely breaks 43430a1 support.
Digging a bit deeper, this would *appear* to be one of a couple of
possibilities;
1) brcmf_sdio_hostmail() is missing code to handle a response of type
0x40012
2) The firmware is failing when asked to handle the new requiests, and
is going to la-la land.
Decoding the reply gives us HMB_DATA_DEVREADY or-ed with 0x40010
Since the upper half-word is masked, that leaves us with 0x10 which does
not appear to be a defined state.
The driver does not handle this well, in any event.
My guess is that you are working on top of newer firmware than I have.
Can you let me know what the latest public firmware is, and where I can
get it?
I have version wl0: Aug 29 2016 20:48:16 version 7.45.41.26 (r640327)
FWID 01-4527cfab
Thanks,
-Ian
On 17/07/17 22:31, Arend van Spriel wrote:
>
>
> On 17-07-17 22:41, Ian Molton wrote:
>> On 17/07/17 21:36, Arend van Spriel wrote:
>>
>>> In <debugfs_mountpoint>/brcmfmac/*/forensics, but you have to load the
>>> driver with modules parameter 'ignore_probe_fail=1' to avoid the driver
>>> remove tearing down all debugfs stuff.
>>
>> modinfo shows:
>>
>> parm: txglomsz:Maximum tx packet chain size [SDIO] (int)
>> parm: debug:Level of debug output (int)
>> parm: p2pon:Enable legacy p2p management functionality (int)
>> parm: feature_disable:Disable features (int)
>> parm: alternative_fw_path:Alternative firmware path (string)
>> parm: fcmode:Mode of firmware signalled flow control (int)
>> parm: roamoff:Do not use internal roaming engine (int)
>>
>
> Seems you did not build with CONFIG_BRCMDBG?
No - it failed the build last time I tried, and I havent had a chance to
look into why yet.
Possibly its fixed since - last I tried was around 4.12-rc4 or something.
-Ian
Hi Arend,
This is all there is in the forensics file, hope its of some use.
# cat /sys/kernel/debug/brcmfmac/mmc1\:0001\:1/forensics
Enter
hndarm_armr addr: 0x18003000, cr4_idx: 0
000000.000
RTE (SDIO-CDC) 7.45.41.26 (r640327) on BCM43430 r1 @ 37.4/81.0/81.0MHz
000000.001 sdpcmdcdc0: Broadcom SDPCMD CDC driver
000000.005 reclaim section 0: Returned 47716 bytes to the heap
000000.007 wlc_bmac_info_init: host_enab 1
000000.025 wl0: Broadcom BCM43430 802.11 Wireless Controller 7.45.41.26
(r640327)
000000.026 TCAM: 256 used: 179 exceed:0
000000.027 reclaim section 1: Returned 81268 bytes to the heap
-Ian
On 17-07-17 20:31, Ian Molton wrote:
> On 17/07/17 18:50, Ian Molton wrote:
>> Resent due to subject error. Apologies, Hante :)
>>
>> Hi Folks,
>>
>> 9fe929aaace6 brcmfmac: add firmware feature detection for gscan feature
>>
>> Completely breaks 43430a1 support.
>
> Digging a bit deeper, this would *appear* to be one of a couple of
> possibilities;
>
> 1) brcmf_sdio_hostmail() is missing code to handle a response of type
> 0x40012
> 2) The firmware is failing when asked to handle the new requiests, and
> is going to la-la land.
taken a wrong turn straight into la-la land.
> Decoding the reply gives us HMB_DATA_DEVREADY or-ed with 0x40010
>
> Since the upper half-word is masked, that leaves us with 0x10 which does
> not appear to be a defined state.
>
> The driver does not handle this well, in any event.
>
> My guess is that you are working on top of newer firmware than I have.
> Can you let me know what the latest public firmware is, and where I can
> get it?
>
> I have version wl0: Aug 29 2016 20:48:16 version 7.45.41.26 (r640327)
> FWID 01-4527cfab
Not so much newer firmware, but I used a different chip when
implementing the multi-scheduled scan patches. I tried some other
devices, but not the bcm4343{0,8}. Now as far as I can see over here the
brcmfmac43430-sdio.bin is not built with gscan support so it should just
return firmware errorcode, ie. -23. So it would be interesting to see
what firmware has to say. Can you load the driver with
ignore_probe_fail=1 and dump the forensics file in debugfs.
Regards,
Arend