Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Level 1

8 points

Windows 10: BCM43xx S3 resume firmware initialization problem (MacBook Pro 15 mid 2014)

Hel!o!

Seems to be there is a serious bug in BCM43xx adapter firmware (MacBook Pro 15 mid 2014) resulting in failed S3 resume initialization (wake-up from Sleep) under Windows 10.

Detection algorithm:

1. Using Device Manager completely uninstall Broadcom 802.11ac network driver with option "Delete the driver software for the device".

2. Press "Scan for hardware changes" button to detect device instance named as "Network Adapter" and select "View" -> "Show hidden devices" from menu, so you can see only one "Network Adapter" device.

3. Put your computer into sleep mode by selecting "Power" -> "Sleep" from start menu and some times later resume it by pressing space bar for eg. Now you can see another detected (duplicated) "Network Adapter" device instance as active, but the first one becomes inactive. This is because failed adapter firmware initialization on S3 resume.

4. Reboot your computer, open Device Manager again with "View" -> "Show hidden devices" option to see (vice versa) the first "Network Adapter" device instance as active, but another one (duplicated) becomes inactive. As a result you always have annoying problem with wi-fi network connection after sleep mode until reboot.

Of course you can repeat steps with Broadcom 802.11ac network driver installed, it doesn't matter, because the Apple should provide us with firmware update to solve this hardware problem.

Any other ideas?

Best Regards.

MacBook Pro with Retina display, Windows 10

Posted on Jan 12, 2016 1:33 PM

46 replies

Loner T

Level 9

59,477 points

Jan 31, 2016 9:53 AM in response to softhive

softhive wrote:

"As a test, delete both instances of the adapter after you come out of sleep, scan for hardware changes, and check if you get only one instance and whether it work properly. What SSD resource are you trying to 'save' in Sleep mode?"

I did that and got duplicated device instance after reboot/poweron, so it's not a solution. It looks like after Sleep mode device initialized differently then after reboot or power on (firmware bug). On Hibernate mode the SSD writes whole 16Gb DRAM data each time that reduces its write cycles resource significantly.

What is the model/controllers of your SSD? If you do not want your SSD to be used, there is a very simple solution. Move the Hiberfil.sys, Pagefil.sys to an external HDD with a fast enough interface. Modern SSDs handle wear-leveling better than older generation SSDs. Page file read/writes are much more taxing on the SSD.

"There is a single physical device, even if there are two instances of the adapter/driver. It is unlikely that the new instance created has credential information for the same wireless access points as the phantom. This can be confirmed by attempting a connection which should result in a failure from the new instance. The only case it may work is if you connect to open SSIDs without any security/keys. I have a 2013 15-in rMBP and a 13-in 2012 MBP. Are you looking for my information?"

As the jdoupe wrote, the problem occures after Sleep mode and disappears after Reboot/Poweron that points to the same behavior as I detected in my case. I'd like to test the same Broadcom wireless adapter in Toshiba laptop to get confirmed evidences of firmware bug, so I need the exact model name and firmware version for Wi-Fi Airport Card of:MBP Retina, 15" early 2013 and MBP Retina 15" mid 2014 (A1398).

The Broadcom may not work in a regular PC due to differences.

"Is the W10 installation on Toshiba using BIOS or UEFI? Atheros and Broadcom are not the same. I have seen sleep work on many PCs without any issues, and it works on OS X side, without any issues. EFI issues would cause a failure overtime, but that is not the case either. It is the interaction between the S3 Resume and the Windows Kernel. The only real solution is to debug the driver and kernel, and find out why this interaction creates a second instance. On my 2012 MBP, I do not see this behavior under W8.1."

Who is responsible for development and bugs of the Apple EFI, the Apple or a customer? In this case the Atheros and the Broadcom are both using the same PCIe interface. My model of Apple Airport adapter has a bug in firmware implementation, but yours probably hasn't. Who must provide corrected firmware update, the Apple or a customer?

This is not EFI, but the interaction between EFI and a Driver, and a specific state transition. Your suggestion that it is an EFI issue, is not quite right. The same EFI works as designed on the OS X side, so why is the EFI an issue?

softhive Author

Level 1

8 points

Jan 31, 2016 11:35 AM in response to Loner T

"This is not EFI, but the interaction between EFI and a Driver, and a specific state transition. Your suggestion that it is an EFI issue, is not quite right. The same EFI works as designed on the OS X side, so why is the EFI an issue?"

I also provided the screenshots of test with no driver installed with the same result (diplicated Apple Airport device instance ) here Re: Windows 10: BCM43xx S3 resume firmware initialization problem (MacBook Pro 15 mid 2014)

Could the Apple be so kind to contact the Broadcom to request a firmware update for built-in Apple Airport Adapter of my MBP Retina 15" mid 2014 (A1398) that corrects the S3 resume initialization bug of built-in Apple Airport Adapter?

Adapter details from MAC OS X El Capitan v10.11.3:

Card Type: Airport Extreme (0x14E4, 0x134)

Firmware Version: Broadcom BCM43xx 1.0 (7.21.94.136.1a1)

Adapter details from BootCamp Windows 10:

Broadcom 802.11ac Network Adapter

PCI\VEN_14E4&DEV_43A0&SUBSYS_0134106B&REV_03

Loner T

Level 9

59,477 points

Jan 31, 2016 2:26 PM in response to softhive

I cannot see your rGhost files. Can you post them as screen shots using the Camera icon.

Here are my testing results on W7 with rMBP2013.

1. Card and Machine Details. Notice the firmware version of the 802.11ac card. I have an older firmware than you do.

2. Original configuration prior to first keep test.

2. Device Manager configuration after first sleep test. Notice the Adapter instance is now 2. I can connect successfully to my home network.

3. Device Manager configuration after second sleep test. The adapter instance is now number 3.

The PCI Vendor information is

My connection to my home network using instance 3.

softhive Author

Level 1

8 points

Feb 1, 2016 5:23 AM in response to Loner T

Here are my testing results on BootCamp Windows 10 x64:

1. My Device Manager configuration prior to first Sleep test (you have to select the "View->Show hidden devices" menu option!). As far as I assume it looks like yours if you would have deleted the "Broadcom 802.11ac Network Adapter #2" device instance which is hidden on your screenshot. I can Reboot/PowerOn/Hibernate my computer many times to see the same picture, but not Sleep.

2. My Device Manager configuration after first Sleep test (you have to select the "View->Show hidden devices" menu option!). Now you can see the phantom "Broadcom 802.11ac Network Adapter #2" device instance which is active, but the first one is inactive (failed adapter firmware S3 Resume initialization). In this case I have lost network connection until Reboot/PowerOn. As far as I can see you have one more phantom "Broadcom 802.11ac Network Adapter #3" device instance, so you have the same bug in Apple Airport Adapter firmware.

3. Here is the same test with no driver installed with the same result, so we have the S3 resume firmware initialization bug of built-in Apple Airport Adapter.

Loner T

Level 9

59,477 points

Feb 1, 2016 5:44 AM in response to softhive

If the bug was in EFI, it would behave the same way in OS X as well. There is a new UUID being generated for the same 'Unknown' device by the OS kernel. Using your last screen shot, what is the UUID of each of the instances of Network Adapters in the registry? Do they point to the same physical device?

softhive Author

Level 1

8 points

Feb 2, 2016 11:45 AM in response to Loner T

I have found the bug! Have a look at device instance path before and after Sleep, especially the SUBSYS value.

Device instance path before Sleep:

PCI\VEN_14E4&DEV_43A0&SUBSYS_0134106B&REV_03\60F800FFFF00000100

Device instance path after Sleep:

PCI\VEN_14E4&DEV_43A0&SUBSYS_0112106B&REV_03\60F800FFFF00000100

As far as I have already told it is the S3 resume firmware initialization bug of built-in Apple Airport Adapter. 😎

How long should we wait for a firmware update to correct this issue?

Loner T

Level 9

59,477 points

Feb 2, 2016 12:30 PM in response to softhive

I will check when I have a chance. The Instance path can change based on PCIe discovery order.

softhive Author

Level 1

8 points

Feb 2, 2016 2:03 PM in response to Loner T

"The Instance path can change based on PCIe discovery order."

It's incorrect because the SUBSYS is part of the Unique Hardware ID: PCI\VEN_14E4&DEV_43A0&SUBSYS_0134106B&REV_03

Sole PCIe device must report sole Hardware ID each time without changes.

Loner T

Level 9

59,477 points

Feb 2, 2016 2:05 PM in response to softhive

Run OSX ioreg command and check after paths of devices before and after sleep on the OSX side.

Loner T

Level 9

59,477 points

Feb 2, 2016 2:30 PM in response to softhive

This is what I see in ioreg.

deviceid: 0x43a0

radiorev: 0x42069000

chipnum: 0x4360

chiprev: 0x3

corerev: 0x2a

boardid: 0x134

boardvendor: 0x106b

boardrev: 0x1418

driverrev: 0x61edf9a

ucoderev: 0x3400075

bus: 0x1

Can you check if your ioreg returns the same values? It should.

Is your W10 installation EFI or BIOS?

softhive Author

Level 1

8 points

Feb 3, 2016 4:05 AM in response to Loner T

Having decoded the Hardware IDs before and after Sleep we can get more information.

Hardware ID before Sleep (PCI\VEN_14E4&DEV_43A0&SUBSYS_0134106B&REV_03) reported:

Network controller [0280]: Broadcom Corporation BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03)

Subsystem: Apple Inc. Device [106b:0134]

Hardware ID after Sleep (PCI\VEN_14E4&DEV_43A0&SUBSYS_0112106B&REV_03) reported:

Network controller [0280]: Broadcom Corporation BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03)

Subsystem: Apple Inc. Device [106b:0112]

As you can see the Broadcom OEM specific data is correct, but the Apple specific data (SUBSYS) is changed after Sleep (incorrect behavior). The SSID and SVID can be changed either from network controller firmware (most often and correct way), or from S3 bootscript (that probably keeps wrong value). Your OS X ioreg test probably checked only main pair of VID:DID. My Windows 10 test checked complete data and determined the device state as not connected. If you provide me with exact ioreg command line parameters then I will make the test to you also.

I made my clean Windows 10 installation by using the OS X BootCamp Assistance utility. For more information let me know what exactly should I check and where.

PS: As you can see it's certainly the Apple bug.

Loner T

Level 9

59,477 points

Feb 3, 2016 6:57 AM in response to softhive

Testing the same adapter on W8.1 using EFI Boot...

1. Before Sleep...

2. After Sleep...

softhive Author

Level 1

8 points

Feb 3, 2016 10:48 AM in response to Loner T

Do you see the hardware id PCI\VEN_14E4&DEV_43A0&SUBSYS_0112106B&REV_03) on your screenshots? If it changed to the same value after Sleep could you explain me what were you testing?

My Air Port card has the hardware id PCI\VEN_14E4&DEV_43A0&SUBSYS_0134106B&REV_03

Do you see the difference between 12 and 34?

Cold you please be so kind to read my previous post Re: Windows 10: BCM43xx S3 resume firmware initialization problem (MacBook Pro 15 mid 2014) carefully?

Loner T

Level 9

59,477 points

Feb 3, 2016 10:56 AM in response to softhive

On the second Mac with W8.1, the SubSys does not change across Sleep/Wake, yet there are two instances of the same card. This is an EFI installation of W8.1, not a BIOS W7 installation. The EFI installation has W8.1 OS communicating with the EFI layer directly. If the SubSys does not change on W8.1, it is interesting that it does change on W10. This is why I asked if your W10 installation is UEFI or BIOS. It may be a CSM-BIOS bug, not necessarily an EFI bug.

Ioreg (ioreg -lw0) only returns one instance of the Device, with the 0x134 (board-id) which stays the same across multiple sleep/wake events on the OSX side, which is using the same EFI layer as used by W8.1. The SybSys id does not change. I will check the ioreg on the W8.1 to confirm it matches the board-id.

The S3 boot script using the incorrect value may also be an issue, as you indicate.

softhive Author

Level 1

8 points

Feb 3, 2016 3:08 PM in response to Loner T

"This is why I asked if your W10 installation is UEFI or BIOS. It may be a CSM-BIOS bug, not necessarily an EFI bug."

I hadh't saw an option to select EFI or CSM installation in BootCamp Assistance, and I used MS Windows Media Creation Tool image on USB Flash. Is there a way to check it from installed Windows 10? I don't see blinking cursor in the upper-left corner of display before Windows startup screen, so probably it's EFI mode.

Here is my ioreg test before and after Sleep:

deviceid: 0x43a0

radiorev: 0x42069

chipnum: 0x4360

chiprev: 0x3

corerev: 0x2a

boardid: 0x134

boardvendor: 0x106b

boardrev: 0x2420

driverrev: 0x7155e88

ucoderev: 0x0

bus: 0x1

Windows 10: BCM43xx S3 resume firmware initialization problem (MacBook Pro 15 mid 2014)