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

1. If you disable sleep/hibernate in Windows, do you get a single instance, after you close/re-open the lid of the MBP? W7/W8.1+ have a lot of bugs in Sleep/Hibernate area. I have seen PnP Failures. There is a very long thread about SD Cards being lost after Sleep/Wake.

2. The second set of links are related to speed, not really a wake-sleep/issue. These issues could stem from environmental issues, they could be hardware issues, they could also be related to OS protocols. For example, AWDL in El Capitan makes the WiFi connection instantiation slower than Mavericks or lower version of OS X, on the same hardware.

3. This does not necessarily imply the situation is perfect. OS X seems to exhibit fewer such issues than Windows on a Mac. Windows on a PC also seems to be different. One option to test would be to run in Windows Safe Mode with Networking and see if changes the behavior.

softhive wrote:

1. Resume after Sleep (S3 resume) duplicates device instance for Broadcom 802.11ac adapter in Device Manager when I close then open the lid. Resume after Hibernate works fine as I have already described above. But I need Sleep mode working perfect to save SSD resource.

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?

2. jdoupe wrote: "I have an MBP (Retina, 15", early 2013), now with 10.10.4, and I still experience this issue (slow wifi after waking from sleep - wifi speed is fine after full shutdown / re-start)."

Probably after walking from sleep both identical duplicated device instances were initialized simultaneously (main and phantom) that resulted in traffic interference and speed reduce. Could you tell me 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)?

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?

3. Common speaking about everything is speaking about nothing. So I have provided exact explanation with 100% reproducible test, and pictures. I just need certain solution for certain hardware problem from Apple. By the way, I have one more laptop from Toshiba with Qualcomm Atheros Wi-Fi adapter that works fine after Sleep (S3 resume) without device duplication in Windows 10. Probably the problem is not in Windows, but in wireless adapter firmware, isn't it?

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.

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?

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?

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?

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

1. Before Sleep...

2. After Sleep...

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.

I seem to have a different (older) board in the 2013 rMBP.

boardrev: 0x1418

driverrev: 0x61edf9a

ucoderev: 0x3400075

bus: 0x1

compared to yours

boardrev: 0x2420

driverrev: 0x7155e88

ucoderev: 0x0

bus: 0x1

I will check the W8.1 Mac tonight and post what I get.

From the 13-in rMBP, This is a completely different 802.11ac card. It does have a different board-id.

deviceid: 0x43a0

radiorev: 0x42069000

chipnum: 0x4360

chiprev: 0x3

corerev: 0x2a

boardid: 0x112

boardvendor: 0x106b

boardrev: 0x2420

driverrev: 0x61edf9a

ucoderev: 0x3400075

bus: 0x1