This issue is not probably not specific to the code. Is your access-point perhaps on channel 13? If so this might be a known issue that we fixed already. If I am not mistaken that will be in v4.2 kernel for which merge window just started.

If you can easily reproduce, you may compile brcmfmac with CONFIG_BRCMDBG set and load the driver with debug=0xd416. That will provide us with more logging to confirm the issue.

Hi,

Thanks for your fast reply !!

Unfortunately no Channel 13 networks around the spot where the crash happened (only Channels 1 - 11, here in Europe, France).

Reproducable: So far not. As I mentioned I wasn't really doing something specific (other than editing a Google Docs Text document).

So I activated CONFIG_BRCMDBG (and CONFIG_BRCM_TRACING), will load brcmfmac with 
debug=0xd416 and wait ... :)
... and come back once I have more info.

Thanks again,

Tormen

Hah. Got it ;)

Found a spot where the problem is reproducible !

uname -a
Linux banana 4.1.0-banana08-43-desktop #1 SMP PREEMPT Mon Jun 29 11:53:46 UTC 2015 (5ee367d) x86_64 x86_64 x86_64 GNU/Linux

The kernel used:
https://build.opensuse.org/package/show/home:tormen/kernel-desktop
Except that in my version, I have enabled:

CONFIG_BRCM_TRACING=y
CONFIG_BRCMDBG=y

And booted with kernel cmdline parameter : brcmfmac.debug=0xd416

Tormen

Created attachment 181541 [details]
journalctl -b -1 # after having restarted from the crash

Created attachment 181551 [details]
iwlist scan # output after having restarted from the crash

without moving from the place where the issue is reproducible

Hi,

Can you see if the new kernel oops (seemingly coming from brmfmac (*)) can be fixed by you guys and/or to what it could be related ?

(*) Call Trace:
[<ffffffffa056d695>] cfg80211_inform_bss_width+0x85/0x2b0 [cfg80211]
[<ffffffffa0656f25>] brcmf_inform_single_bss+0x175/0x210 [brcmfmac]

Is there anything else I can provide / do to help ?

Thanks a lot in advance for any hint.

Tormen

I have more and more crashes these last days :

Unfortunately without debug output activated (but maybe still helpful), here the last lines before the full-system-freeze (mouse, keyboard) from journalctl -b -1:

Jul 02 17:17:26 banana NetworkManager[1388]: (NetworkManager:1388): libnm-util-CRITICAL **: get_secret_flags: a
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Activation (wlp3s0) Stage 1 of 5 (Device Prepare) scheduled
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Activation (wlp3s0) Stage 1 of 5 (Device Prepare) started..
Jul 02 17:17:26 banana NetworkManager[1388]: <info> (wlp3s0): device state change: need-auth -> prepare (reason
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Activation (wlp3s0) Stage 2 of 5 (Device Configure) schedul
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Activation (wlp3s0) Stage 1 of 5 (Device Prepare) complete.
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Activation (wlp3s0) Stage 2 of 5 (Device Configure) startin
Jul 02 17:17:26 banana NetworkManager[1388]: <info> (wlp3s0): device state change: prepare -> config (reason 'n
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Activation (wlp3s0/wireless): connection 'Local' has securi
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Config: added 'ssid' value 'Local'
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Config: added 'scan_ssid' value '1'
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Config: added 'auth_alg' value 'OPEN'
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Config: added 'psk' value '<omitted>'
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Activation (wlp3s0) Stage 2 of 5 (Device Configure) complet
Jul 02 17:17:26 banana NetworkManager[1388]: <info> Config: set interface ap_scan to 1
Jul 02 17:17:26 banana NetworkManager[1388]: <info> (wlp3s0): supplicant interface state: inactive -> scanning
Jul 02 17:17:26 banana NetworkManager[1388]: <info> (wlp3s0): supplicant interface state: scanning -> associati
Jul 02 17:17:27 banana NetworkManager[1388]: <info> (wlp3s0): supplicant interface state: associating -> discon
Jul 02 17:17:27 banana NetworkManager[1388]: <info> (wlp3s0): supplicant interface state: disconnected -> scann
Jul 02 17:17:27 banana NetworkManager[1388]: <info> (wlp3s0): supplicant interface state: scanning -> associati
Jul 02 17:17:27 banana NetworkManager[1388]: <info> (wlp3s0): supplicant interface state: associating -> discon
Jul 02 17:17:28 banana sudo[2494]: pam_unix(sudo:session): session closed for user root
Jul 02 17:17:28 banana NetworkManager[1388]: <info> (wlp3s0): supplicant interface state: disconnected -> scann
Jul 02 17:17:29 banana NetworkManager[1388]: <info> (wlp3s0): supplicant interface state: scanning -> associati
Jul 02 17:17:29 banana NetworkManager[1388]: <info> (wlp3s0): supplicant interface state: associating -> discon
Jul 02 17:17:34 banana NetworkManager[1388]: <info> (wlp3s0): supplicant interface state: disconnected -> scann
Jul 02 17:17:35 banana kernel: brcmf_dev_pno_clean: failed code -52
Jul 02 17:17:35 banana kernel: brcmf_cfg80211_sched_scan_start: failed error=-52

Hi,

I seem out of luck: More and more crashes. So many and so often, that I can't work on wifi anymore.

A bit devastating especially in combination with this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=100191
which prevents usage of the wired network after unplugging it once (something I need to do frequently on my notebook).

Tormen

Created attachment 181731 [details]
journalctl -b -1 # with full debug output after having restarted from the crash

This crash showed some new messages (from what I glanced), notably this one:

kernel: Fixing recursive fault but reboot is needed!

(In reply to Tormen from comment #9)
> Created attachment 181731 [details]
> journalctl -b -1 # with full debug output after having restarted from the
> crash
> 
> This crash showed some new messages (from what I glanced), notably this one:
> 
> kernel: Fixing recursive fault but reboot is needed!

This message is consequential to the actual bug. The logs confirm my suspicion and you two patches that are in 4.2-rc1:

8afe0ec brcmfmac: update wiphy band information upon updating regulatory domain
58de92d brcmfmac: use static superset of channels for wiphy bands

The patches above apply cleanly to both 4.0.7 and 4.1.0 so they can be submitted to stable to resolve this issue.

Thanks a lot for your feedback !

I will (for now) add them to my Macbook patchset and get back to you.

Dear Arend,

I applied the patch and the crash did not happen again. But instead I am sometimes unable to connect to these networks (that before lead to the kernel freezes).

I did reboot with debug and did several connection attempts and at the end connected to my Android Hotspot network, which so far always worked fine.

I'll attach the debug output.

I really have the feeling that there must be another / a follow-up bug.

It would be really great if you could have a look and of course please let me know if you'd need anything else.

Thanks a lot in advance,

Tormen

Created attachment 182881 [details]
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c (4.1.1 kernel with latest patches)

Here is my currently used drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c

kernel 4.1.1 + 2 patches:

8afe0ec brcmfmac: update wiphy band information upon updating regulatory domain
58de92d brcmfmac: use static superset of channels for wiphy bands

See Comment #10 : https://bugzilla.kernel.org/show_bug.cgi?id=100201#c10

Created attachment 182891 [details]
journalctl -b0 # after restarting + trying and failing to connect

After reboot : Tried several times and failed every time to "Campus" WIFI network, then successfully connecting to Android Hotspot.

Hi,

it is really strange : 

1.) At the place in our office where I was able to constantly 100% reproduce the kernel freeze, I can now (with the 2 patches you mentioned) connect without problem.

2.) But where I had no problem to connect before (at my desk ;)) to the same network, but physically different location, so other access point) I cannot connect any more with my notebook. With my Android I have no problems in both locations.

:(

Can you make any sense out of that ? - Hopefully by looking through the attached kernel log ?

Tormen

Sorry... my block 2.) was not done yet. So I post this again:

Hi,

it is really strange : 

1.) At the place in our office where I was able to constantly 100% reproduce the kernel freeze, I can now (with the 2 patches you mentioned) connect without problem.

2.) But where I had no problem to connect before (*) I cannot connect any more with my notebook. With my Android I have no problems in both locations.

(*) Before I could connect without problem at my desk to the same network, but at a physically different location than the "crash-location", so using another access point

:(

Can you make any sense out of that ? - Hopefully by looking through the attached kernel log ?

Tormen

A similar freeze issue happens on my asus laptop (using ath3k dongle) and my Haswell NUC (using centrino wireless 2300) when trying ti use the K810 keyboard.

The MacBook devices may require different firmware. Will see if we can release that sometime soon.

(In reply to Arend van Spriel from comment #19)
> The MacBook devices may require different firmware. Will see if we can
> release that sometime soon.

To confirm the firmware need can you provide me some debugfs info:

$ sudo -i
$ cat /sys/kernel/debug/brcmfmac/*/revinfo

Thanks a lot for your answer and please let me know if I can help further.

Here is the information you requested:

for a in /sys/kernel/debug/brcmfmac/*/revinfo; do echo "\"$a\""; cat "$a"; done

"/sys/kernel/debug/brcmfmac/0000:03:00.0/revinfo"
vendorid: 0x14e4
deviceid: 0x4318
radiorev: 0.7.32.105
chipnum: 43602 (aa52)
chiprev: 1
chippkg: 0
corerev: 49
boardid: 0x061b
boardvendor: 0x14e4
boardrev: P421
driverrev: 7.35.177.36
ucoderev: 0
bus: 0
phytype: 11
phyrev: 18
anarev: 0
nvramrev: 00000000

For now I am using this firmware:

[   19.725528] brcmf_c_preinit_dcmds: Firmware version = wl0: Mar 13 2015 08:11:08 version 7.35.177.36 (r540934) FWID 01-e4dc15b
[   19.742375] brcmf_cfg80211_reg_notifier: not a ISO3166 code
[   19.752167] brcmfmac 0000:03:00.0 wlp3s0: renamed from wlan0

As mentioned before (Comment #17, 2.) point): I am unable to connect to the two WLAN networks used at work: Campus + Local
I don't know why.
But this seems to indicate a(nother?) problem with the brcm firmware and/or brcmfmac driver,  
because with all other devices (e.g. with my Android Smartphone) or operating systems (e.g. for my colleagues under Windows) : No problem.

To hopefully allow you to understand what's going on:
Please find attached several journalctl outputs (done after several steps),
using the kernel 4.1.3.

Created attachment 185631 [details]
journalctl_-b0___nr.0_after-fresh-boot-up_and_before-any-connection.txt

Created attachment 185641 [details]
journalctl_-b0___nr.1_after-successfull-connecting-to-android-hotspot.txt

Created attachment 185651 [details]
journalctl_-b0___nr.2_after-failing-to-connect-to_first_CAMPUS-network_and_then_LOCAL-network_everytime_falling-back-to_android-hotspot.txt

Created attachment 185661 [details]
iw infos for the failed connects to CAMPUS + LOCAL

By any chance are those networks you cannot see on 5GHz? The Arch wiki has a note about not being able to see any 5GHz networks, and I have the same experience on my macbook.

Created attachment 185671 [details]
iwlist wlp3s0 scanning output for the failed connects to CAMPUS + LOCAL

I just noticed that "iw dev wlp3s0 scan" was not what I wanted ;)

The networks are visible (with Network Manager and CLI tools).

... and they are not 5Ghz:

E.g.: CAMPUS:
          Cell 06 - Address: 00:23:EA:00:F3:B0
                    Channel:13
                    Frequency:2.472 GHz (Channel 13)
                    Quality=60/70  Signal level=-50 dBm  
                    Encryption key:on
                    ESSID:"Campus"
                    Bit Rates:5.5 Mb/s; 6 Mb/s; 9 Mb/s; 11 Mb/s; 12 Mb/s
                              18 Mb/s; 24 Mb/s; 36 Mb/s
                    Bit Rates:48 Mb/s; 54 Mb/s

Created attachment 185741 [details]
Complete system lockup while "rmmod brcmfmac" !


And I stumbled across another issue with brcmfmac driver:

While connected to WLAN here at home, I tried to rmmod brcmfmac.

The result : A complete system lockup :((

The highlights:

Aug 24 23:38:18 banana kernel: BUG: unable to handle kernel paging request at 000000000000340f
Aug 24 23:38:18 banana kernel: IP: [<ffffffff8169ff69>] mutex_lock+0x9/0x22
Aug 24 23:38:18 banana kernel: PGD 438d3e067 PUD 439f4b067 PMD 0 
Aug 24 23:38:18 banana kernel: Oops: 0002 [#1] PREEMPT SMP

And this is reproducible.

Possibly useful and related information:

    Blacklisting brcmfmac module helps getting SUSPEND to work!

See: https://bugzilla.kernel.org/show_bug.cgi?id=101681
And also possibly this one: https://bugzilla.kernel.org/show_bug.cgi?id=103211

I have just noticed that the MAC address for my card in Linux is set incorrectly. It is set to 00:90:4c:0d:f4:3e for everyone I know who has this card (3 people). That isn't the correct physical address for any one of us. But perhaps this should be a separate issue?

Thanks a lot for this info.

Ineed, for me too!

This is bad :(

... and might possibly explain my WLAN connection issues, if there is a MAC collision...  

How can I verify/assure if/that I have the newest firmware ?

Basically, 14e4:43ba is currently unusable on Linux if there is another user nearby. I have two friends at university who both run Linux with the same wireless card as me, if any two of us are in the vicinity of each other, we cannot use wireless, even if we change to our correct MAC addresses first.

Hi Arend,

The malfunction of the brcmfmac driver is developping with the new kernel version 4.2.0 :

First the good news :
   + all patches I had to apply to 4.1 are included now :)
   + I was unable to make the computer crash by "rmmod brcmfmac" (so far)


The (really) bad news :

With the 4.2.0 kernel *ANY* wifi activity stops working after a couple of MINUTES.

The driver then gets in a sort of non-functional STASIS (where it looses it's connection and is unable to scan, connect, ...).

Where the only way I found to scan + connect is rmmod brcmfmac; modprobe brcmfmac :(((

I'll attach some files showing the problem!

Tormen

Created attachment 187871 [details]
2015-09-17 : after system boot-up and wifi that was first working first "failed bus is not ready" dmesg errors

Created attachment 187881 [details]
2015-09-17 : dmesg 2/3 : Now right after rmmod + modprobe and wifi working again

Created attachment 187891 [details]
2015-09-17 : dmesg 3/3 : and few minutes later : again "failed bus is not ready" dmesg errors !


Here are some additional commands I ran to probe the state of the network card in this non-functional STASIS :

 root@banana /learn/it # rfkill list
3: phy3: Wireless LAN
        Soft blocked: no
        Hard blocked: no
 root@banana /learn/it # ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
23: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:90:4c:0d:f4:3e brd ff:ff:ff:ff:ff:ff
 root@banana /learn/it # iw dev wlp3s0 info
Interface wlp3s0
        ifindex 23
        wdev 0x300000001
        addr 00:90:4c:0d:f4:3e
        type managed
        wiphy 3
 root@banana /learn/it # iw dev wlp3s0 link
Not connected.
 root@banana /learn/it # iwlist scan       
lo        Interface doesn't support scanning.

wlp3s0    Interface doesn't support scanning : Network is down

 root@banana /learn/it # iw dev wlp3s0 scan                             
command failed: Network is down (-100)

Regarding further breakage in kernel 4.2: This is not my experience at all. Running 4.2-4 from ArchLinux testing repo at the moment, for 13 hours today, and wireless is stable, albeit still with the issues discussed regarding 5GHz functionality and MAC address. But it's definitely not worse than before.

(In reply to Adrian Bjugård from comment #40)
> Regarding further breakage in kernel 4.2: This is not my experience at all.

This is my experience too, although I am using 4.2.0 from Gentoo, gentoo-sources-4.2.0-r1, and the subsystem shown by lspci is different.

04:00.0 0280: 14e4:43ba (rev 01)
	Subsystem: 106b:0152

(In reply to Adrian Bjugård from comment #35)
> Basically, 14e4:43ba is currently unusable on Linux if there is another user
> nearby. I have two friends at university who both run Linux with the same
> wireless card as me, if any two of us are in the vicinity of each other, we
> cannot use wireless, even if we change to our correct MAC addresses first.

Can you use random MACs to work around the address duplication issue? I am using the systemd instructions from Arch on Gentoo without issue:

https://wiki.archlinux.org/index.php/MAC_address_spoofing#Method_1:_systemd-networkd

(In reply to Tim Sammut from comment #42)
> (In reply to Adrian Bjugård from comment #35)
> > Basically, 14e4:43ba is currently unusable on Linux if there is another
> user
> > nearby. I have two friends at university who both run Linux with the same
> > wireless card as me, if any two of us are in the vicinity of each other, we
> > cannot use wireless, even if we change to our correct MAC addresses first.
> 
> Can you use random MACs to work around the address duplication issue? I am
> using the systemd instructions from Arch on Gentoo without issue:
> 
> https://wiki.archlinux.org/index.php/MAC_address_spoofing#Method_1:_systemd-
> networkd

I've tried to use macchanger, it doesn't seem to work for me.

For the record I have the same subsystem reported as Tormen, 106b:0133, and my setup works fine as previously stated.

Hi,

thanks for the feedback !! 

Could you be so kind to state what firmware version you are using ?

Should look like this in "dmesg" output:
[  719.562965] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Mar 13 2015 08:11:08 version 7.35.177.36 (r540934) FWID 01-e4dc15b

You might need to add these kernel-parameters to get this:
       brcmfmac.debug=0xd416
and for systemd potentially:
       systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

Thanks in advance !

Tormen

(In reply to Tormen from comment #44)
>
> Could you be so kind to state what firmware version you are using ?
> 

This is from my 11,5 machine with 4.2.0 from Gentoo which seems to work well:

[   23.928988] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Mar 13 2015 08:11:08 version 7.35.177.36 (r540934) FWID 01-e4dc15b

And

[    0.000000] DMI: Apple Inc. MacBookPro11,5/Mac-06F11F11946D27C5, BIOS MBP114.88Z.0172.B00.1503301047 03/30/2015

$ sudo lspci -vvk | grep -A1 04:00
04:00.0 Network controller: Broadcom Corporation BCM43602 802.11ac Wireless LAN SoC (rev 01)
	Subsystem: Apple Inc. BCM43602 802.11ac Wireless LAN SoC

$ sudo lspci -vvnk | grep -A1 04:00
04:00.0 0280: 14e4:43ba (rev 01)
	Subsystem: 106b:0152


hope this helps
tim

(In reply to Tim Sammut from comment #45)
> (In reply to Tormen from comment #44)
> >
> > Could you be so kind to state what firmware version you are using ?
> > 
> 
> This is from my 11,5 machine with 4.2.0 from Gentoo which seems to work well:

> 
> [   23.928988] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Mar
> 13 2015 08:11:08 version 7.35.177.36 (r540934) FWID 01-e4dc15b

So you are using the same firmware!

... but as you pointed out in comment 41, your subsystem is different and you are using the 43ba in an older version of the Macbook.

sudo lspci -vvk |grep -A1 "Network controller"
 03:00.0 Network controller: Broadcom Corporation Device 43ba (rev 01)
	Subsystem: Apple Inc. Device 0133

sudo lspci -vvnk | grep -A1 :43ba
 03:00.0 0280: 14e4:43ba (rev 01)
	Subsystem: 106b:0133

@Broadcom / @Arend :

Not sure if this can be consistant with the fact that for me it really does not work :(

Also is there anything that I can do to zoom in further on the problem, or are the dmesg with debug enabled that I attached are enough ?

> So you are using the same firmware!
> 
> ... but as you pointed out in comment 41, your subsystem is different and
> you are using the 43ba in an older version of the Macbook.
> 

Sorry to split hairs, but in case it helps. The 11,5 is actually slightly newer (Mid 2015) than the 12,1 (early 2015). 

https://support.apple.com/en-gb/HT201300

Hehe.
I just somehow assumed that the number 11,5 ... 12,1 would be increasingly numbering the models ;) - So thanks for the info ! 
and I like precision :)

The most important difference between 12,1 and 11,5 are the processor models (Broadwell [1] vs Haswell [2] respectively) and thus different chipsets as well.

[1] http://www.everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-i7-3.1-13-early-2015-retina-display-specs.html
[2] http://www.everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-i7-2.8-15-dual-graphics-mid-2015-retina-display-specs.html

I have a MacBookPro11,4

kernel 4.2.0-rc8-mainline from Arch's mainline package also with these changes:
+CONFIG_BRCM_TRACING=y
+CONFIG_BRCMDBG=y

Card version:
[   73.593858] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Mar 13 2015 08:11:08 version 7.35.177.36 (r540934) FWID 01-e4dc15b

$ lspci -vvk | grep -A1 Network
03:00.0 Network controller: Broadcom Corporation BCM43602 802.11ac Wireless LAN SoC (rev 01)
	Subsystem: Apple Inc. Device 0152

$ lspci -vvn\k | grep -A1 43ba
03:00.0 0280: 14e4:43ba (rev 01)
	Subsystem: 106b:0152

Wifi is totally stable, but 5GHz is not found, and it takes 60 seconds to load on startup.

Same results for wireless on 4.3-rc1; except it breaks virtualbox so I'm sticking to 4.2 for now.

Merci Justin ! - How is Europe ? :))

> Wifi is totally stable,
I envie you ;)

--------------

As the issue seems to be limited to the 12,1 version :

Anybody with a 12,1 MacBookPro12,1 (2015 Retina 13") as well ?

Tormen

(In reply to Tormen from comment #51)
> Merci Justin ! - How is Europe ? :))
> 
> > Wifi is totally stable,
> I envie you ;)
> 
> --------------
> 
> As the issue seems to be limited to the 12,1 version :
> 
> Anybody with a 12,1 MacBookPro12,1 (2015 Retina 13") as well ?
> 
> Tormen

I have a MBP12,1, no issues for me except the 5GHz and MAC address.

for my MBP12,1 the issues I see are 5GHz, MAC address, and suspend / poweroff issues that are possibly caused by brcmfmac (see bugs ref'ed above)

(In reply to thejoe from comment #53)
> for my MBP12,1 the issues I see are 5GHz, MAC address, and suspend /
> poweroff issues that are possibly caused by brcmfmac (see bugs ref'ed above)

The same issuses in my MBP 11,5 and I have the same suspect

(In reply to Tormen from comment #37)
> Created attachment 187871 [details]
> 2015-09-17 : after system boot-up and wifi that was first working first
> "failed bus is not ready" dmesg errors

So could you repeat with more debugging enabled, ie. debug=0x81416.

Hi Arend,

For now I was using brcmfmac.debug=0xd416, I now changed to brcmfmac.debug=0x81416.
I'll let you know. Should I try this debug setting with the old firmware ?

Because since I am using the new firmware :
I did not experience this problem anymore :)
But I am still testing to see if I can see any persistant traits of misbehaviour.
So far I can state that overall I see less connection problems, but still some things seem odd. For instance I'd say since the time I am using the new firmware I got a few times into problem that notebook did not want to wakup from sleep ... eneded to hard-reset (force-off) the notebook. Not sure yet where this comes from.

(In reply to Tormen from comment #56)
> Hi Arend,
> 
> For now I was using brcmfmac.debug=0xd416, I now changed to
> brcmfmac.debug=0x81416.
> I'll let you know. Should I try this debug setting with the old firmware ?
> 
> Because since I am using the new firmware :
> I did not experience this problem anymore :)
> But I am still testing to see if I can see any persistant traits of
> misbehaviour.
> So far I can state that overall I see less connection problems, but still
> some things seem odd. For instance I'd say since the time I am using the new
> firmware I got a few times into problem that notebook did not want to wakup
> from sleep ... eneded to hard-reset (force-off) the notebook. Not sure yet
> where this comes from.

There's new firmware? Are you sure you don't mean new driver patches? If there is new firmware, where do I find it? I've been watching http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/log/ for new firmware, is there somewhere else I should look?

(In reply to Adrian Bjugård from comment #57)
> (In reply to Tormen from comment #56)
> > Hi Arend,
> > 
> > For now I was using brcmfmac.debug=0xd416, I now changed to
> > brcmfmac.debug=0x81416.
> > I'll let you know. Should I try this debug setting with the old firmware ?
> > 
> > Because since I am using the new firmware :
> > I did not experience this problem anymore :)
> > But I am still testing to see if I can see any persistant traits of
> > misbehaviour.
> > So far I can state that overall I see less connection problems, but still
> > some things seem odd. For instance I'd say since the time I am using the
> new
> > firmware I got a few times into problem that notebook did not want to wakup
> > from sleep ... eneded to hard-reset (force-off) the notebook. Not sure yet
> > where this comes from.
> 
> There's new firmware? Are you sure you don't mean new driver patches? If
> there is new firmware, where do I find it? I've been watching
> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/log/
> for new firmware, is there somewhere else I should look?

X2 new firmware? and you can suspend to ram? using some workaround like deactivate XHCI?

Suspend to ram : Please see bug : https://bugzilla.kernel.org/show_bug.cgi?id=101681

(In reply to Tormen from comment #56)
> Hi Arend,
> 
> For now I was using brcmfmac.debug=0xd416, I now changed to
> brcmfmac.debug=0x81416.
> I'll let you know. Should I try this debug setting with the old firmware ?

you may, but not sure if it will give much clues.

> Because since I am using the new firmware :
> I did not experience this problem anymore :)
> But I am still testing to see if I can see any persistant traits of
> misbehaviour.
> So far I can state that overall I see less connection problems, but still
> some things seem odd. For instance I'd say since the time I am using the new
> firmware I got a few times into problem that notebook did not want to wakup
> from sleep ... eneded to hard-reset (force-off) the notebook. Not sure yet
> where this comes from.

"sleep" means suspend-to-ram, right? You could try following:

# echo devices > /sys/power/pm_test
# echo mem > /sys/power/state

and provide dmesg output.

(In reply to Arend van Spriel from comment #60)
> 
> "sleep" means suspend-to-ram, right? You could try following:
> 
> # echo devices > /sys/power/pm_test
> # echo mem > /sys/power/state
> 
> and provide dmesg output.


sleep == suspend-to-ram, yes.

When I do "systemctl suspend" while X/KDE running, it works.

When I do the 2 above commands :
# echo devices > /sys/power/pm_test
# echo mem > /sys/power/state

The first command returns. The second command does a sleep, but wakes up 4-5 seconds later by itself (screen comes back on) accompanied by a complete system hang.
I tried it 2x. Both times the same result.
Looking at journalctl -b -1 did not reveal anything.

Created attachment 188191 [details]
2015-09-23 test results


I then did 3 tests in "init 1" single user mode:
  * 1st_init-1_trial : "systemctl suspend" 		with "cat /proc/acpi/wakeup" showing ARPT, XHC1 and LID0 *enabled*
  * 2nd_init-1_trial : "echo mem > /sys/power/state" 	with "cat /proc/acpi/wakeup" showing *only* ARPT enabled
  * 3rd_init-1_trial : "systemctl suspend" 		with "cat /proc/acpi/wakeup" showing *only* ARPT enabled
  * 4th-trial_under-kde_after_rmmod-brcmfmac : see info.txt for issued commands

Please find all results in the attached .zip file.

Can we please skip these unimportant instability issues and focus on getting the driver to set the correct MAC address and sub-channels? At the moment the driver is LITERALLY unusable if there are more than one bcm43602 users trying to use the same network. At my university there are now 6 of us running linux which means we actually can't use our laptops. What needs to be done? Is it Broadcom we need to nag? Are they not signing off on new firmware releases? What's the deal?

Sorry Adrian, I won't skip reporting instability issues that lead to a complete kernel FREEZE. It's why I opened the bug (see title of bug ;)).

But I am glad that you mentioned the problem(s) ! And am happy to push forward with the problems that you added to this bug!
(see also my mail I sent to you)

I was able to get 5GHz to work with the new firmware that was posted by Arend van Spriel. You can read more at http://marc.info/?l=linux-wireless&m=144312043720069

If you want to give the blob a try, check:
https://github.com/rsalveti/ubuntu-linux-firmware/blob/wily-brcmfmac/brcm/brcmfmac43602-pcie.ap.bin
https://github.com/rsalveti/ubuntu-linux-firmware/blob/wily-brcmfmac/brcm/brcmfmac43602-pcie.bin

Just replace your current firmware at /lib/firmware/brcm and reload the module.

(In reply to Ricardo Salveti de Araujo from comment #65)
> I was able to get 5GHz to work with the new firmware that was posted by
> Arend van Spriel. You can read more at
> http://marc.info/?l=linux-wireless&m=144312043720069

I can confirm that this solves the 5GHz issue on the MBP 11,5. Suspend/resume still does not work.

(In reply to Ricardo Salveti de Araujo from comment #65)
> I was able to get 5GHz to work with the new firmware that was posted by
> Arend van Spriel. You can read more at
> http://marc.info/?l=linux-wireless&m=144312043720069
> 
> If you want to give the blob a try, check:
> https://github.com/rsalveti/ubuntu-linux-firmware/blob/wily-brcmfmac/brcm/
> brcmfmac43602-pcie.ap.bin
> https://github.com/rsalveti/ubuntu-linux-firmware/blob/wily-brcmfmac/brcm/
> brcmfmac43602-pcie.bin
> 
> Just replace your current firmware at /lib/firmware/brcm and reload the
> module.

I can confirm too 5Ghz networks are visible in my MBP 11,5

Created attachment 189711 [details]
newly released firmware supporting MacBookPro 2015 wifi device

The new firmware contains support for the 43602 wifi device found in MacBook Pro 2015 edition.

(In reply to Arend van Spriel from comment #68)
> Created attachment 189711 [details]
> newly released firmware supporting MacBookPro 2015 wifi device
> 
> The new firmware contains support for the 43602 wifi device found in MacBook
> Pro 2015 edition.

This firmware has been published to the linux-firmware repository as well.

Hi,

With none of the driver (from the kernel, and the one discussed above) I can't get the wifi to work.
"iwlist scan" show me the available wifi around me, then it seems able to log in WPA mode. Once logged in, wicd show me a poor quality (0/100) then disconnect after 1sec.
I don't know what more information to give you, please just ask.

# dmidecode -s system-product-name
MacBookPro12,1
[
# uname -a
Linux lamontagne 4.2.2-1-ARCH #1 SMP PREEMPT Tue Sep 29 22:21:33 CEST 2015 x86_64 GNU/Linux

# modprobe -v brcmfmac                                              
insmod /lib/modules/4.2.2-1-ARCH/kernel/drivers/mmc/core/mmc_core.ko.gz 
insmod /lib/modules/4.2.2-1-ARCH/kernel/drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko.gz 
insmod /lib/modules/4.2.2-1-ARCH/kernel/drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.ko.gz debug=0x81416

# dmesg
...
[  856.524269] usbcore: registered new interface driver brcmfmac
[  856.524931] brcmfmac 0000:03:00.0: Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2
[  857.048381] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 18 2015 03:29:47 version 7.35.177.56 (r587209) FWID 01-f0a43dc2
[  857.074330] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code


Around the authentification process to the router, I get the following trace in dmesg

[ 1653.439427] ------------[ cut here ]------------
[ 1653.439436] WARNING: CPU: 2 PID: 2365 at net/wireless/sme.c:981 cfg80211_connect+0x224/0x6d0 [cfg80211]()
[ 1653.439437] Modules linked in: brcmfmac brcmutil mmc_core rndis_host cdc_ether usbnet mii dm_crypt sha256_ssse3 sha256_generic hmac drbg ansi_cprng algif_skcipher af_alg dm_mod ax25 bnep snd_hda_codec_hdmi input_leds joydev btusb btrtl btbcm btintel mousedev hid_apple hid_generic bluetooth usbhid hid bcm5974 nvram msr iTCO_wdt iTCO_vendor_support mac_hid evdev intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel applesmc led_class input_polldev kvm crct10dif_pclmul crc32_pclmul crc32c_intel wl(PO) i915 ghash_clmulni_intel snd_hda_codec_cirrus snd_hda_codec_generic aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd cfg80211 snd_hda_intel drm_kms_helper snd_hda_codec drm snd_hda_core snd_hwdep snd_pcm rfkill bdc_pci snd_timer pcspkr intel_gtt snd i2c_algo_bit
[ 1653.439468]  mei_me i2c_i801 soundcore mei shpchp lpc_ich acpi_als ac battery sbs kfifo_buf sbshc industrialio spi_pxa2xx_platform apple_bl video button processor sch_fq_codel ip_tables x_tables ext4 crc16 mbcache jbd2 sd_mod uas usb_storage ahci libahci libata scsi_mod xhci_pci xhci_hcd usbcore usb_common [last unloaded: brcmutil]
[ 1653.439483] CPU: 2 PID: 2365 Comm: iwconfig Tainted: P        W  O    4.2.2-1-ARCH #1
[ 1653.439484] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B07.1506051617 06/05/2015
[ 1653.439486]  0000000000000000 00000000500b03f1 ffff880453033b38 ffffffff8156b9da
[ 1653.439487]  0000000000000000 0000000000000000 ffff880453033b78 ffffffff81074886
[ 1653.439489]  ffff88046effad80 ffff88045b0931b0 ffff88045b093008 ffff880428700000
[ 1653.439490] Call Trace:
[ 1653.439495]  [<ffffffff8156b9da>] dump_stack+0x4c/0x6e
[ 1653.439498]  [<ffffffff81074886>] warn_slowpath_common+0x86/0xc0
[ 1653.439499]  [<ffffffff810749ba>] warn_slowpath_null+0x1a/0x20
[ 1653.439502]  [<ffffffffa03f2484>] cfg80211_connect+0x224/0x6d0 [cfg80211]
[ 1653.439506]  [<ffffffffa040dde9>] ? cfg80211_mgd_wext_connect+0xc9/0x1d0 [cfg80211]
[ 1653.439509]  [<ffffffffa040de75>] cfg80211_mgd_wext_connect+0x155/0x1d0 [cfg80211]
[ 1653.439512]  [<ffffffffa040dfdc>] cfg80211_mgd_wext_siwfreq+0xec/0x200 [cfg80211]
[ 1653.439515]  [<ffffffff811c0595>] ? mem_cgroup_end_page_stat+0x25/0x50
[ 1653.439518]  [<ffffffffa040dd08>] cfg80211_wext_siwfreq+0x108/0x120 [cfg80211]
[ 1653.439520]  [<ffffffff815588e2>] ioctl_standard_call+0x52/0xe0
[ 1653.439522]  [<ffffffff8126e498>] ? security_capable+0x48/0x60
[ 1653.439523]  [<ffffffff81559570>] ? iw_handler_get_private+0x60/0x60
[ 1653.439524]  [<ffffffff81558890>] ? call_commit_handler.part.3+0x30/0x30
[ 1653.439526]  [<ffffffff81558814>] wireless_process_ioctl+0x164/0x1b0
[ 1653.439527]  [<ffffffff81558b78>] wext_handle_ioctl+0x78/0xd0
[ 1653.439529]  [<ffffffff8148b7f0>] dev_ioctl+0x290/0x560
[ 1653.439531]  [<ffffffff81455876>] sock_ioctl+0x126/0x290
[ 1653.439532]  [<ffffffff811e29e5>] do_vfs_ioctl+0x295/0x480
[ 1653.439534]  [<ffffffff811e2c49>] SyS_ioctl+0x79/0x90
[ 1653.439536]  [<ffffffff81570f6e>] entry_SYSCALL_64_fastpath+0x12/0x71
[ 1653.439537] ---[ end trace be52932cfc6b0b48 ]---
[ 1653.445164] ------------[ cut here ]------------
[ 1653.445173] WARNING: CPU: 2 PID: 2366 at net/wireless/sme.c:981 cfg80211_connect+0x224/0x6d0 [cfg80211]()
[ 1653.445174] Modules linked in: brcmfmac brcmutil mmc_core rndis_host cdc_ether usbnet mii dm_crypt sha256_ssse3 sha256_generic hmac drbg ansi_cprng algif_skcipher af_alg dm_mod ax25 bnep snd_hda_codec_hdmi input_leds joydev btusb btrtl btbcm btintel mousedev hid_apple hid_generic bluetooth usbhid hid bcm5974 nvram msr iTCO_wdt iTCO_vendor_support mac_hid evdev intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel applesmc led_class input_polldev kvm crct10dif_pclmul crc32_pclmul crc32c_intel wl(PO) i915 ghash_clmulni_intel snd_hda_codec_cirrus snd_hda_codec_generic aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd cfg80211 snd_hda_intel drm_kms_helper snd_hda_codec drm snd_hda_core snd_hwdep snd_pcm rfkill bdc_pci snd_timer pcspkr intel_gtt snd i2c_algo_bit
[ 1653.445205]  mei_me i2c_i801 soundcore mei shpchp lpc_ich acpi_als ac battery sbs kfifo_buf sbshc industrialio spi_pxa2xx_platform apple_bl video button processor sch_fq_codel ip_tables x_tables ext4 crc16 mbcache jbd2 sd_mod uas usb_storage ahci libahci libata scsi_mod xhci_pci xhci_hcd usbcore usb_common [last unloaded: brcmutil]
[ 1653.445220] CPU: 2 PID: 2366 Comm: iwconfig Tainted: P        W  O    4.2.2-1-ARCH #1
[ 1653.445221] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B07.1506051617 06/05/2015
[ 1653.445222]  0000000000000000 000000008c69a761 ffff88045315bb58 ffffffff8156b9da
[ 1653.445224]  0000000000000000 0000000000000000 ffff88045315bb98 ffffffff81074886
[ 1653.445226]  0000000000000000 ffff88045b0931b0 ffff88045b093008 ffff880428700000
[ 1653.445227] Call Trace:
[ 1653.445232]  [<ffffffff8156b9da>] dump_stack+0x4c/0x6e
[ 1653.445235]  [<ffffffff81074886>] warn_slowpath_common+0x86/0xc0
[ 1653.445236]  [<ffffffff810749ba>] warn_slowpath_null+0x1a/0x20
[ 1653.445239]  [<ffffffffa03f2484>] cfg80211_connect+0x224/0x6d0 [cfg80211]
[ 1653.445243]  [<ffffffffa040dde9>] ? cfg80211_mgd_wext_connect+0xc9/0x1d0 [cfg80211]
[ 1653.445246]  [<ffffffffa040de75>] cfg80211_mgd_wext_connect+0x155/0x1d0 [cfg80211]
[ 1653.445249]  [<ffffffffa040e60c>] cfg80211_mgd_wext_siwap+0x16c/0x1c0 [cfg80211]
[ 1653.445252]  [<ffffffffa040d84c>] cfg80211_wext_siwap+0xec/0x1c0 [cfg80211]
[ 1653.445254]  [<ffffffff815588e2>] ioctl_standard_call+0x52/0xe0
[ 1653.445256]  [<ffffffff8126e498>] ? security_capable+0x48/0x60
[ 1653.445257]  [<ffffffff81559570>] ? iw_handler_get_private+0x60/0x60
[ 1653.445258]  [<ffffffff81558890>] ? call_commit_handler.part.3+0x30/0x30
[ 1653.445259]  [<ffffffff81558814>] wireless_process_ioctl+0x164/0x1b0
[ 1653.445261]  [<ffffffff81558b78>] wext_handle_ioctl+0x78/0xd0
[ 1653.445263]  [<ffffffff8148b7f0>] dev_ioctl+0x290/0x560
[ 1653.445265]  [<ffffffff81455876>] sock_ioctl+0x126/0x290
[ 1653.445267]  [<ffffffff811e29e5>] do_vfs_ioctl+0x295/0x480
[ 1653.445268]  [<ffffffff811e2c49>] SyS_ioctl+0x79/0x90
[ 1653.445270]  [<ffffffff81570f6e>] entry_SYSCALL_64_fastpath+0x12/0x71
[ 1653.445271] ---[ end trace be52932cfc6b0b49 ]---



Some informations on the AP:
 Channel:1
 Frequency:2.412 GHz (Channel 1)
 Quality=57/70  Signal level=-53 dBm  
 Encryption key:on
 ESSID:"Bbox-2..."
 Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
    24 Mb/s; 36 Mb/s; 54 Mb/s
 Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s

I am very confused, for my first post I was wrong.

After digging a bit more, it seems it is related to wicd and not the driver provided by Arend van Spriel. When using wpa_supplicant and dhcpch manually it works, but with wicd running the card receive a disconnect event locally generated.

Anyway, sorry for the noise and thanks every one!

(In reply to Arend van Spriel from comment #68)
>
> The new firmware contains support for the 43602 wifi device found in MacBook
> Pro 2015 edition.

Thank you for this.

Does this firmware image also fix the duplicate MAC address issue?

Yes. The new firmware does set the correct MAC address and sub-channels.

Created attachment 197871 [details]
dmesg -T from : brcmfmac got "stuck" somehow ! (probably after wakeup from suspend) ... and finally got working again after many rmmod / modprobe brcmfmac...

Dear Arend,

I just ran into a problem with brcmfmac : brcmfmac got "stuck" somehow ! (probably after wakeup from suspend)

Meaning : The module was loaded, ifconfig showed the interface, but it was not usable. dmesg showed kernel oopses !

I then tried to rmmod brcmfmac and modprobe brcmfmac /many/ times. It still did not work and finally while preparing proper debug output for you, I started working again :((

I attached the FINAL dmesg output after it started working again. Hopefully you can still get an idea of the problem.

Please let me know.
Potentially please advise if I should check something specific next time around. 

Otherwise I will pay attention to catch this nasty little bug(ger) better on camera next time around ;)

Happy holidays !!

Tormen