Hi
After firmware update, this device:
[0280]: Broadcom Limited BCM4356 802.11ac Wireless Network Adapter [14e4:43ec] (rev 02)
no longer initialize. With the firmware update I have:
[ 272.063814] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x000002
[ 272.529582] brcmfmac 0000:03:00.0: irq 31 for MSI/MSI-X
[ 274.529476] brcmfmac: brcmf_msgbuf_query_dcmd: Timeout on response for query command
[ 274.537356] brcmfmac: brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -5
[ 274.544881] brcmfmac: brcmf_bus_started: failed: -5
[ 274.549854] brcmfmac: brcmf_pcie_attach_bus: dongle is not responding
and no wlan device is created. With older version of the firmware I have:
[ 10.716878] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x000002
[ 11.312875] brcmfmac 0000:03:00.0: irq 31 for MSI/MSI-X
[ 11.314735] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
[ 16.598211] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
[ 16.604416] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-dev-wlp3s0 type 10 failed: err=-16
and despite P2P errors, device works correctly.
Regards
Stanislaw
On 12/14/2017 3:22 PM, Stanislaw Gruszka wrote:
> On Thu, Dec 14, 2017 at 10:13:29AM +0100, Arend van Spriel wrote:
>> The cur_etheraddr is the first piece of info we try to get from the
>> firmware. Could you build the driver with CONFIG_BRCMDBG and load
>> the module with 'debug=0x181416'.
>
> dmesg attached.
So the firmware console output in the dmesg shows partial stack trace
which clearly means the firmware crashed.
[ 2685.701602] brcmfmac: brcmf_pcie_isr_thread Enter 100
[ 2685.701613] brcmfmac: brcmf_pcie_handle_mb_data D2H_MB_DATA: 0x10000000
[ 2685.701634] brcmfmac: CONSOLE: 0d
[ 2685.701706] brcmfmac: CONSOLE: 000000.049 sp+ec 00184635
[ 2685.701778] brcmfmac: CONSOLE: 000000.049 sp+f4 00182ca7
[ 2685.701854] brcmfmac: CONSOLE: 000000.049 sp+100 000001df
[ 2685.701928] brcmfmac: CONSOLE: 000000.049 sp+140 0000823f
[ 2685.702003] brcmfmac: CONSOLE: 000000.049 sp+150 0018b8d9
[ 2687.642667] brcmfmac: brcmf_msgbuf_query_dcmd: Timeout on response
for query command
[ 2687.650464] brcmfmac: brcmf_fil_cmd_data Failed: BCME_NOTDOWN (-5)
[ 2687.650469] brcmfmac: brcmf_fil_iovar_data_get ifidx=0,
name=cur_etheraddr, len=6
[ 2687.650471] brcmutil: data
[ 2687.650475] 00000000: 00 00 00 00 00 00
......
[ 2687.650479] brcmfmac: brcmf_c_preinit_dcmds: Retreiving cur_etheraddr
failed, -5
I noticed you are not using a nvram file. Do you know if one was
orignally provided with the device?
Regards,
Arend
Hi
On Wed, Dec 20, 2017 at 09:46:59AM +0100, Arend van Spriel wrote:
> I had my colleague run some tests as he has the device, but he is an ocean
> away. So he could get the new firmware running with nvram file. For the old
> firmware the device could boot without nvram, but the scan results were
> showing that the device was not operating optimally. Could you try the new
> firmware with the attached sample nvram file and let me know if that works
> for you?
Yes. After placing the nvram file to /lib/firmware/brcm/brcmfmac4356-pcie.txt
device now initalize with the new firmware. Is this right fix, IOW should this
file be shiped in linux-firmware ?
Thanks
Stanislaw
On Tue, Dec 19, 2017 at 12:36:36PM +0100, Arend van Spriel wrote:
> On 12/15/2017 1:20 PM, Stanislaw Gruszka wrote:
> >On Fri, Dec 15, 2017 at 12:10:34PM +0100, Arend van Spriel wrote:
> >># cat /sys/kernel/debug/brcmfmac/0000:03:00.0/revinfo
> >
> >vendorid: 0x14e4
> >deviceid: 0x43ec
> >radiorev: 0.41.32.105
> >chipnum: 17238 (4356)
> >chiprev: 2
> >chippkg: 2
> >corerev: 48
> >boardid: 0x0777
> >boardvendor: 0x14e4
> >boardrev: P103
> >driverrev: 7.35.180.119
> >ucoderev: 0
> >bus: 0
> >phytype: 11
> >phyrev: 17
> >anarev: 0
> >nvramrev: 00000000
>
> Thanks for the info. I was looking for the board info. It seems we
> do not have an nvram file for that specific board.
>
> For SDIO devices I would suggest to use the module parameter
> 'ignore_probe_fail' so we could do post-mortem stuff with the driver
> bound to the device, but for PCIe there are not much debug options.
> Let me work on that. May take a bit longer though.
What about the revert of the firmware change if proper
fix can not be soon available ?
Cheers
Stanislaw
On Fri, Dec 15, 2017 at 10:58:10AM +0100, Arend van Spriel wrote:
> On 12/14/2017 3:22 PM, Stanislaw Gruszka wrote:
> >On Thu, Dec 14, 2017 at 10:13:29AM +0100, Arend van Spriel wrote:
> >>The cur_etheraddr is the first piece of info we try to get from the
> >>firmware. Could you build the driver with CONFIG_BRCMDBG and load
> >>the module with 'debug=0x181416'.
> >
> >dmesg attached.
>
> So the firmware console output in the dmesg shows partial stack
> trace which clearly means the firmware crashed.
>
> [ 2685.701602] brcmfmac: brcmf_pcie_isr_thread Enter 100
> [ 2685.701613] brcmfmac: brcmf_pcie_handle_mb_data D2H_MB_DATA: 0x10000000
> [ 2685.701634] brcmfmac: CONSOLE: 0d
> [ 2685.701706] brcmfmac: CONSOLE: 000000.049 sp+ec 00184635
> [ 2685.701778] brcmfmac: CONSOLE: 000000.049 sp+f4 00182ca7
> [ 2685.701854] brcmfmac: CONSOLE: 000000.049 sp+100 000001df
> [ 2685.701928] brcmfmac: CONSOLE: 000000.049 sp+140 0000823f
> [ 2685.702003] brcmfmac: CONSOLE: 000000.049 sp+150 0018b8d9
> [ 2687.642667] brcmfmac: brcmf_msgbuf_query_dcmd: Timeout on
> response for query command
> [ 2687.650464] brcmfmac: brcmf_fil_cmd_data Failed: BCME_NOTDOWN (-5)
> [ 2687.650469] brcmfmac: brcmf_fil_iovar_data_get ifidx=0,
> name=cur_etheraddr, len=6
> [ 2687.650471] brcmutil: data
> [ 2687.650475] 00000000: 00 00 00 00 00 00 ......
> [ 2687.650479] brcmfmac: brcmf_c_preinit_dcmds: Retreiving
> cur_etheraddr failed, -5
>
> I noticed you are not using a nvram file. Do you know if one was
> orignally provided with the device?
I think it was not. The device was bought and setup in Fedora/RHEL
machine, which do not include any extra brcmfmac nvram file.
Thanks
Stanislaw
On 12/15/2017 11:32 AM, Stanislaw Gruszka wrote:
> On Fri, Dec 15, 2017 at 10:58:10AM +0100, Arend van Spriel wrote:
>> On 12/14/2017 3:22 PM, Stanislaw Gruszka wrote:
>>> On Thu, Dec 14, 2017 at 10:13:29AM +0100, Arend van Spriel wrote:
>>>> The cur_etheraddr is the first piece of info we try to get from the
>>>> firmware. Could you build the driver with CONFIG_BRCMDBG and load
>>>> the module with 'debug=0x181416'.
>>>
>>> dmesg attached.
>>
>> So the firmware console output in the dmesg shows partial stack
>> trace which clearly means the firmware crashed.
>>
>> [ 2685.701602] brcmfmac: brcmf_pcie_isr_thread Enter 100
>> [ 2685.701613] brcmfmac: brcmf_pcie_handle_mb_data D2H_MB_DATA: 0x10000000
>> [ 2685.701634] brcmfmac: CONSOLE: 0d
>> [ 2685.701706] brcmfmac: CONSOLE: 000000.049 sp+ec 00184635
>> [ 2685.701778] brcmfmac: CONSOLE: 000000.049 sp+f4 00182ca7
>> [ 2685.701854] brcmfmac: CONSOLE: 000000.049 sp+100 000001df
>> [ 2685.701928] brcmfmac: CONSOLE: 000000.049 sp+140 0000823f
>> [ 2685.702003] brcmfmac: CONSOLE: 000000.049 sp+150 0018b8d9
>> [ 2687.642667] brcmfmac: brcmf_msgbuf_query_dcmd: Timeout on
>> response for query command
>> [ 2687.650464] brcmfmac: brcmf_fil_cmd_data Failed: BCME_NOTDOWN (-5)
>> [ 2687.650469] brcmfmac: brcmf_fil_iovar_data_get ifidx=0,
>> name=cur_etheraddr, len=6
>> [ 2687.650471] brcmutil: data
>> [ 2687.650475] 00000000: 00 00 00 00 00 00 ......
>> [ 2687.650479] brcmfmac: brcmf_c_preinit_dcmds: Retreiving
>> cur_etheraddr failed, -5
>>
>> I noticed you are not using a nvram file. Do you know if one was
>> orignally provided with the device?
>
> I think it was not. The device was bought and setup in Fedora/RHEL
> machine, which do not include any extra brcmfmac nvram file.
If the supplier of the device did not include such file it is probably
not needed.
When using the old (working) firmware could you dump revinfo file in
debugfs, ie.:
# cat /sys/kernel/debug/brcmfmac/0000:03:00.0/revinfo
Thanks,
Arend
On 12/19/2017 1:23 PM, Stanislaw Gruszka wrote:
> On Tue, Dec 19, 2017 at 12:36:36PM +0100, Arend van Spriel wrote:
>> On 12/15/2017 1:20 PM, Stanislaw Gruszka wrote:
>>> On Fri, Dec 15, 2017 at 12:10:34PM +0100, Arend van Spriel wrote:
>>>> # cat /sys/kernel/debug/brcmfmac/0000:03:00.0/revinfo
>>>
>>> vendorid: 0x14e4
>>> deviceid: 0x43ec
>>> radiorev: 0.41.32.105
>>> chipnum: 17238 (4356)
>>> chiprev: 2
>>> chippkg: 2
>>> corerev: 48
>>> boardid: 0x0777
>>> boardvendor: 0x14e4
>>> boardrev: P103
>>> driverrev: 7.35.180.119
>>> ucoderev: 0
>>> bus: 0
>>> phytype: 11
>>> phyrev: 17
>>> anarev: 0
>>> nvramrev: 00000000
>>
>> Thanks for the info. I was looking for the board info. It seems we
>> do not have an nvram file for that specific board.
>>
>> For SDIO devices I would suggest to use the module parameter
>> 'ignore_probe_fail' so we could do post-mortem stuff with the driver
>> bound to the device, but for PCIe there are not much debug options.
>> Let me work on that. May take a bit longer though.
>
> What about the revert of the firmware change if proper
> fix can not be soon available ?
Hi Stanislaw,
I had my colleague run some tests as he has the device, but he is an
ocean away. So he could get the new firmware running with nvram file.
For the old firmware the device could boot without nvram, but the scan
results were showing that the device was not operating optimally. Could
you try the new firmware with the attached sample nvram file and let me
know if that works for you?
Regards,
Arend
On Fri, Dec 15, 2017 at 12:10:34PM +0100, Arend van Spriel wrote:
> # cat /sys/kernel/debug/brcmfmac/0000:03:00.0/revinfo
vendorid: 0x14e4
deviceid: 0x43ec
radiorev: 0.41.32.105
chipnum: 17238 (4356)
chiprev: 2
chippkg: 2
corerev: 48
boardid: 0x0777
boardvendor: 0x14e4
boardrev: P103
driverrev: 7.35.180.119
ucoderev: 0
bus: 0
phytype: 11
phyrev: 17
anarev: 0
nvramrev: 00000000
Regards
Stanislaw
On Thu, Dec 14, 2017 at 10:13:29AM +0100, Arend van Spriel wrote:
> The cur_etheraddr is the first piece of info we try to get from the
> firmware. Could you build the driver with CONFIG_BRCMDBG and load
> the module with 'debug=0x181416'.
dmesg attached.
Thanks
Stanislaw
On 12/13/2017 5:12 PM, Stanislaw Gruszka wrote:
> Hi
>
> After firmware update, this device:
>
> [0280]: Broadcom Limited BCM4356 802.11ac Wireless Network Adapter [14e4:43ec] (rev 02)
>
> no longer initialize. With the firmware update I have:
>
> [ 272.063814] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x000002
> [ 272.529582] brcmfmac 0000:03:00.0: irq 31 for MSI/MSI-X
> [ 274.529476] brcmfmac: brcmf_msgbuf_query_dcmd: Timeout on response for query command
> [ 274.537356] brcmfmac: brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -5
> [ 274.544881] brcmfmac: brcmf_bus_started: failed: -5
> [ 274.549854] brcmfmac: brcmf_pcie_attach_bus: dongle is not responding
>
> and no wlan device is created. With older version of the firmware I have:
>
> [ 10.716878] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x000002
> [ 11.312875] brcmfmac 0000:03:00.0: irq 31 for MSI/MSI-X
> [ 11.314735] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
> [ 16.598211] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
> [ 16.604416] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-dev-wlp3s0 type 10 failed: err=-16
>
> and despite P2P errors, device works correctly.
The cur_etheraddr is the first piece of info we try to get from the
firmware. Could you build the driver with CONFIG_BRCMDBG and load the
module with 'debug=0x181416'.
Regards,
Arend
On 12/15/2017 1:20 PM, Stanislaw Gruszka wrote:
> On Fri, Dec 15, 2017 at 12:10:34PM +0100, Arend van Spriel wrote:
>> # cat /sys/kernel/debug/brcmfmac/0000:03:00.0/revinfo
>
> vendorid: 0x14e4
> deviceid: 0x43ec
> radiorev: 0.41.32.105
> chipnum: 17238 (4356)
> chiprev: 2
> chippkg: 2
> corerev: 48
> boardid: 0x0777
> boardvendor: 0x14e4
> boardrev: P103
> driverrev: 7.35.180.119
> ucoderev: 0
> bus: 0
> phytype: 11
> phyrev: 17
> anarev: 0
> nvramrev: 00000000
Thanks for the info. I was looking for the board info. It seems we do
not have an nvram file for that specific board.
For SDIO devices I would suggest to use the module parameter
'ignore_probe_fail' so we could do post-mortem stuff with the driver
bound to the device, but for PCIe there are not much debug options. Let
me work on that. May take a bit longer though.
Regards,
Arend