No sleep when USB WIFI Connected to USB 3.0 Port

[macdude1]

Hello,
I know USB WiFi is known to cause instabilities, But Is there any way to patch it ? When I ave my USB WiFi (Edimax) connected to USB 3.0 Port, system does not go to sleep. Just the display goes off and stays in that state, even upon pressing any key.

One of My USB 3.0 Does'nt seem to work. What patch should I do in my DSDT. I have attached my IOREG and patchmatic output.

 

[RehabMan]

Hello,
I know USB WiFi is known to cause instabilities, But Is there any way to patch it ? When I ave my USB WiFi (Edimax) connected to USB 3.0 Port, system does not go to sleep. Just the display goes off and stays in that state, even upon pressing any key.

One of My USB 3.0 Does'nt seem to work. What patch should I do in my DSDT. I have attached my IOREG and patchmatic output.

The version of GenericUSBXHCI.kext is likely not built for Yosemite.

My build is universal: https://github.com/RehabMan/OS-X-Generic-USB3

But GenericUSBXHCI.kext should be avoided on Yosemite (it has known problems not likely to be fixed). Better to use AppleUSBXHCI.kext with appropriate DSDT patches (to solve sleep issues).

USB WiFi is not recommended (the drivers are poorly written). Better to use supported PCIe WiFi.

Stay tuned: In a few days, I may have a solution ready for easy XHC->EHC multiplex (with AppleUSBHXHCI.kext) using new FakePCIID kexts.

 

[macdude1]

The version of GenericUSBXHCI.kext is likely not built for Yosemite.

My build is universal: https://github.com/RehabMan/OS-X-Generic-USB3

But GenericUSBXHCI.kext should be avoided on Yosemite (it has known problems not likely to be fixed). Better to use AppleUSBXHCI.kext with appropriate DSDT patches (to solve sleep issues).

As I have told you in an another thread, Using USB 8 series DSDT patch , completely inhibits the sleep itself. And I said that I am going back to GenericUSBXCHI.kext.

USB WiFi is not recommended (the drivers are poorly written). Better to use supported PCIe WiFi.

I have already ordered ar9280 and is on the way. Once I get, I will do the replacement work.

Stay tuned: In a few days, I may have a solution ready for easy XHC->EHC multiplex (with AppleUSBHXHCI.kext) using new FakePCIID kexts.

Already I am visiting GitHub Repo daily, for any new version of kexts . I am waiting for that kext. If you could upload just the source to GitHub, We may build and try it. Thank you for the extended support which , even apple can't provide.

 

[RehabMan]

As I have told you in an another thread, Using USB 8 series DSDT patch , completely inhibits the sleep itself. And I said that I am going back to GenericUSBXCHI.kext.

What do you mean "inhibits sleep"? Do you mean instant wake? If so, there is a solution for that. Read DSDT patching guide: http://www.tonymacx86.com/yosemite-laptop-support/152573-guide-patching-laptop-dsdt-ssdts.html

Already I am visiting GitHub Repo daily, for any new version of kexts . I am waiting for that kext. If you could upload just the source to GitHub, We may build and try it. Thank you for the extended support which , even apple can't provide.

I just pushed the updated source.

The new kext is FakePCIID_XHCIMux.kext.kext. You need the updated FakePCIID.kext installed as well (FakePCIID_XHCIMux.kext depends on it).

 

[macdude1]

What do you mean "inhibits sleep"? Do you mean instant wake? If so, there is a solution for that. Read DSDT patching guide: http://www.tonymacx86.com/yosemite-laptop-support/152573-guide-patching-laptop-dsdt-ssdts.html

Its not instant wake but just the display goes off and nothing comes back. Even pressing any keys did'nt work. I have to force restart.

I just pushed the updated source.

The new kext is FakePCIID_XHCIMux.kext.kext. You need the updated FakePCIID.kext installed as well (FakePCIID_XHCIMux.kext depends on it).

WOW!! Amazing. I am going to try it out.

 

[macdude1]

Can i Remove GenericUSBXCHI.kext ??

 

[RehabMan]

Can i Remove GenericUSBXCHI.kext ??

Since GenericUSBXHCI.kext has an easy to use muxing flag (-gux_defer_usb2) something like FakePCIID_XHCIMux.kext is not needed.

Since AppleUSBXCHI.kext muxing capability is more complex to implement (although I'm figuring it out)..

FakePCIID_XHCIMux.kext is intended to be used with AppleUSBXHCI.

Remove GenericUSBXHCI.kext... you'll then be using AppleUSBXHCI.kext and FakePCIID_XHCIMux.kext should cause USB2 devices plugged into USB3 ports to be handled by AppleUSBEHCI.kext.

 

[macdude1]

Since GenericUSBXHCI.kext has an easy to use muxing flag (-gux_defer_usb2) something like FakePCIID_XHCIMux.kext is not needed.

Since AppleUSBXCHI.kext muxing capability is more complex to implement (although I'm figuring it out)..

FakePCIID_XHCIMux.kext is intended to be used with AppleUSBXHCI.

Remove GenericUSBXHCI.kext... you'll then be using AppleUSBXHCI.kext and FakePCIID_XHCIMux.kext should cause USB2 devices plugged into USB3 ports to be handled by AppleUSBEHCI.kext.

Works perfect and very much better than GenericUSBXCHI.kext. Detects the USB devices instantly , compared to GenericUSBXCHI.kext which takes quite an amount of time. All three USB Ports work. cos ng 90MB/s in USB 3.0.

What remains is that, Sleep gets locked when USB WiFi is plugged in USB 3.0 Port. Whereas with USB2.0, No such problem.

Just for learning , Which are we MUXing actually ?

 

[RehabMan]

Works perfect and very much better than GenericUSBXCHI.kext. Detects the USB devices instantly , compared to GenericUSBXCHI.kext which takes quite an amount of time. All three USB Ports work. cos ng 90MB/s in USB 3.0.

What remains is that, Sleep gets locked when USB WiFi is plugged in USB 3.0 Port. Whereas with USB2.0, No such problem.

Just for learning , Which are we MUXing actually ?

Let's see if I see what is expected...

Post ioreg: http://www.tonymacx86.com/audio/58368-guide-how-make-copy-ioreg.html. Please, use the IORegistryExplorer v2.1 attached to the post! DO NOT reply with an ioreg from any other version of IORegistryExplorer.app.

Muxing is really an inappropriate term, but it has been well established since it is the term Apple uses.

It is really routing (routing USB2 ports on the XCH controller to EHC controller).

Generally, USB WiFi behaves better with AppleUSBEHCI.kext, but it is possible the drivers you're using still have problems there. You should also insure you have the latest drivers for your USB WiFi.

 

[macdude1]

Let's see if I see what is expected...

Post ioreg: http://www.tonymacx86.com/audio/58368-guide-how-make-copy-ioreg.html. Please, use the IORegistryExplorer v2.1 attached to the post! DO NOT reply with an ioreg from any other version of IORegistryExplorer.app.

Muxing is really an inappropriate term, but it has been well established since it is the term Apple uses.

It is really routing (routing USB2 ports on the XCH controller to EHC controller).

Generally, USB WiFi behaves better with AppleUSBEHCI.kext, but it is possible the drivers you're using still have problems there. You should also insure you have the latest drivers for your USB WiFi.

I have attached my IOREG !