Contribute
Register

The Perfect Customac-Pro: X99-A II, i7-6950X, 128GB G.Skill TridentZ, Aorus GTX 1080 TI Xtreme

Status
Not open for further replies.
I only use one internal connector at a time. So, unfortunately, in my case, the connector near the Audio connector didn't work.
Had to switch to the other. This is something relatively new, since 10.12.5 and prior it was working with that connector (and USBGeneric kext and the dsdt patches).

But as you stated, maybe it only works one connector at a time. That, I can't test since I only have 2 front USB (one connector).

It seems that still you did not catch the info we transmitted! The port does not work because it is neither considered nor implemented in the XHC USB Kext we distributed! This has nothing to do with the actual macOS version nor with the case that it might work within an USBInjectAll approach. You can also stay with the latter approach if you are not content with the current XHC USB Kext solution. However, you have been always the one who complained that the latter approach does not work either on your mobo. Now with the XHC USB approach, all required ports are fully functional on the ASUS X99-A II and also reveal correct speeds! You also have even the two front port USB3.0 connectors connected to the second fully implemented and fully functional internal USB 3.0 connector. So let’s say that different from all your previous configurations over many years, you now have for the first time a fully functional USB configuration that also delivers the expected data rates at all required USB2.0, USB3.0 and USB3.1 Type-A and Type-C ports! I would actually expect more happiness,enthusiasm and gratitude at your side... I don’t see any necessity for neverending loop-like discussions! You repeatedly asked for help and support in your neverending USB issues. We did! So what more?

As repeatedly transmitted, he will try to implement the last yet non-functional internal USB3.0 connector in the XHC USB Kext during the weekend. But let me just once more emphasize that this port is not of crucial importance as you anyway can connect your front-panel USB3.0 connectors with the second fully functional internal USB3.0 connector. Instead of permanently arguing and complaining, you are certainly also totally free to write and develop your own XHC USB Kext by following my guideline, which I repeatedly linked before....

Good luck, man! And nothing for bad!

Cheers, KGP
 
Last edited:
No problem! Did you also switched the usb 3.0 connector to the other one nearby the ram slots ?

There is a possibility that we can only activate one USB 3 Port Connector on the board at one time! As soon as bough are active, none of them will work ! Still need further testings which I will do on Thursday night!

For now only the USB Port at the ram slots will work if I delete them the other USB port will work... but this is not an option!

I might have to correct your above statement. Without the not implemented second internal USB3.0 connector, all HS and four SS Ports (SSP1, SSP2, SSP5, SSP6) are properly assigned to the remaining USB2.0 and USB3.0 ports, respectively and everything works as expected. However, the adding of the missing internal USB 3.0 connector requires the additional implementation of HS03, HS04 and SSP3, SSP4. Surprisingly, by doing so, suddenly only SSP1 and SSP2 show up in IOREG, which further implies that all internal and external USB3.0 ports associated to SSP3, SSP4, SSP5 and SSP6 and related HS-Ports become suddenly non-functional or just work at USB2.0 speed. Thus it seems, one has to skip either SSP1 and SSP2 or SSP3 and SSP4 or SSP5 and SSP6 as well as all associated HS-Ports, which further means that one might be able to use both internal USB 3.0 connectors but looses in consequence the functionality of some of the the external USB3.0 connectors when just implementing SSP1, SSP2 (internal USB connector 2), SSP3 and SSP4 (internal USB connector 1) and skipping SSP5 and SSP6 as well as the associated HS-ports. Thus the apparent limitation to 4 active SS-Ports in fact does not only affect the full implementation of the two internal USB3.0 connectors but is rather in general at odd with the correct implementation of all available internal and external USB3.0 ports on the ASUS X99-A II. It just depends on your choice, which 4 SS-Ports out of 6 SS-Ports and associsted HS-Ports addressed by the Asus X99-A II you are implementing. It seems simply impossible to implement or consider all 6 SS-Ports and associated HS-ports at the same time in the XHC USB Kext. Thus either the two internal USB3.0 connectors might work by loosing some external USB3.0 connectors, or just one out of two internal USB3.0 connectors and all external USB3.0 connectors would work at the same time. In case of e.g. the ASUS Prime X299 Deluxe, the association of HS and SS-Ports with all available USB2.0 and USB3.0 ports is solved and implemented in a much smarter way already by factory default. HS01 and HS02, as well as SSP1 and SSP2 are not associated to any of the available USB2.0 and USB3.0 ports! Thus, one just needs to implement SSP3, SSP4, SSP5 and SSP6 and all HS-ports in use and does not touch at all the ill-posed problem apparent above in case of the ASUS X99-A II...

I hope that my above conclusions concerning the Asus X99-A II are just wrong and you still find a solution for implementing all available internal and external USB connectors on the Asus X99-A II. We will see what will be the result of your additional efforts.

Cheers,

KGP

Anyway much rumor and noise about an internal USB3.0 connector, which neither is mandatory nor absolutely required for successfully operating all front and back panel USB3.0 connectors on the ASUS X99-A II ! One can perfectly live with the current XHC USB Kext solution but has to emphasise that one out of two internal USB3.0 connectors is neither considered nor implemented and therefore none-functional within this new and innovative XHC USB Kext approach.
 
Last edited:
I might have to correct your above statement. Without the not implemented second internal USB3.0 connector, all HS and four SS Ports (SSP1, SSP2, SSP5, SSP6) are properly assigned to the remaining USB2.0 and USB3.0 ports, respectively and everything works as expected. However, the adding of the missing internal USB 3.0 connector requires the additional implementation of HS03, HS04 and SSP3, SSP4. Surprisingly, by doing so, suddenly only SSP1 and SSP2 show up in IOREG, which further implies that all internal and external USB3.0 ports associated to SSP3, SSP4, SSP5 and SSP6 and related HS-Ports become suddenly non-functional or just work at USB2.0 speed. Thus it seems, one has to skip either SSP1 and SSP2 or SSP3 and SSP4 or SSP5 and SSP6 as well as all associated HS-Ports, which further means that one might be able to use both internal USB 3.0 connectors but looses in consequence the functionality of some of the the external USB3.0 connectors when just implementing SSP1, SSP2 (internal USB connector 2), SSP3 and SSP4 (internal USB connector 1) and skipping SSP5 and SSP6 as well as the associated HS-ports. Thus the apparent limitation to 4 active SS-Ports in fact does not only affect the full implementation of the two internal USB3.0 connectors but is rather in general at odd with the correct implementation of all available internal and external USB3.0 ports on the ASUS X99-A II. It just depends on your choice, which 4 SS-Ports out of 6 SS-Ports and associsted HS-Ports addressed by the Asus X99-A II you are implementing. It seems simply impossible to implement or consider all 6 SS-Ports and associated HS-ports at the same time in the XHC USB Kext. Thus either the two internal USB3.0 connectors might work by loosing some external USB3.0 connectors, or just one out of two internal USB3.0 connectors and all external USB3.0 connectors would work at the same time. In case of e.g. the ASUS Prime X299 Deluxe, the association of HS and SS-Ports with all available USB2.0 and USB3.0 ports is solved and implemented in a much smarter way already by factory default. HS01 and HS02, as well as SSP1 and SSP2 are not associated to any of the available USB2.0 and USB3.0 ports! Thus, one just needs to implement SSP3, SSP4, SSP5 and SSP6 and all HS-ports in use and does not touch at all the ill-posed problem apparent above in case of the ASUS X99-A II...

I hope that my above conclusions concerning the Asus X99-A II are just wrong and you still find a solution for implementing all available internal and external USB connectors on the Asus X99-A II. We will see what will be the result of your additional efforts.

Cheers,

KGP

Anyway much rumor and noise about an internal USB3.0 connector, which neither is mandatory nor absolutely required for successfully operating all front and back panel USB3.0 connectors on the ASUS X99-A II ! One can perfectly live with the current XHC USB Kext solution but has to emphasise that one out of two internal USB3.0 connectors is neither considered nor implemented and therefore none-functional within this new and innovative XHC USB Kext approach.

I Think you did get the point in my previous post :)

I was not make a tantrum, or demanding any kind of obligation from you, just pinpointing the steps I did, and responding to the part where he said maybe only one connection works at a time.

No hard feelings whatsoever, just trying to help in the "closure" of this motherboard, since, in technological years, it's ageing well :)
 
  • Like
Reactions: kgp
I quoted this part of KGP's tutorial.

Anyways thought I'd directly ask and not beat around the bush.
In the kerneltopatch find and replace directions; how do you do that?




----------------------------------------------------------------------------------------------------------------------------------------------
b) "Kernel and Kext Patches" Section: Verify and add if necessary the following "KernelToPatch" entries:

Code:
Find:                                                             Replace:                                                          Comment:                                  MatchOS:
0fb6c483 c0e983f8 47                                              0fb6c483 c0e183f8 47                                              xcpm_cpuid_set_info © Pike R. Alpha       10.12
8d43c483 f822                                                     8d43c383 f822                                                     xcpm_bootstrap Sierra © Pike R. Alpha     10.12
be070000 0031d2e8 94fcffff                                        be070000 0031d290 90909090                                        xcpm_pkg_scope_msr © Pike R. Alpha        10.12
be020000 0031d2e8 6cfcffff                                        be020000 0031d290 90909090                                        xcpm_core_scope_msrs © Pike R. Alpha      10.12
20b9e200 00000f30                                                 20b9e200 00009090                                                 xcpm_idle patch by Pike R. Alpha          10.12
554889e5 41574156 41554154 53504189d64189f7 4889fb45 85ff0f84     c39089e5 41574156 41554154 53504189d64189f7 4889fb45 85ff0f84     reboot fix 10.12db8 © Pike R. Alpha       10.12

View attachment 269650

----------------------------------------------------------------------------------------------------------------------------------------------
 
1-Download clover configurator.
2- open your plist file with clover configurator
3-in clover configurator go to "kernel and kext patches"
4-bottom part called KerneltoPatch push the plus sign+ will make you a new line will be blue
5-Add in the numbers from the guide to 'find hex'- replace hex'- comment' -and match os

Thanks, I've never done that.

I'd like to ask you another question. You said you used 2699 ssdt in lieu of 2696. Was your E5-2696 V3 unsupported?
I have the E5-
2673 V4 it's equal is E5-2698 v4. Were you able to spoof the ssdtPRGen.sh terminal in someway or not?
If I followed your example; would I just find a E5-2698 V4 ssdt and use it?
 
I did the XCPM KernwlToPatch, there was a pike alpha reboot fix in there already with a slightly different change to. When I ran 'sysctl machdep.xcpm.mode' in terminal it returned '0' My MOBO is ASROCK x99m.
I am hoping that someone here c
an provide some assistance.

Thank-you,
 
I did the XCPM KernwlToPatch, there was a pike alpha reboot fix in there already with a slightly different change to. When I ran 'sysctl machdep.xcpm.mode' in terminal it returned '0' My MOBO is ASROCK x99m.
I am hoping that someone here c
an provide some assistance.

Thank-you,

For first, just try to boot with xcpm_cpu_info and xcpm_bootstrap as well as maybe with the 10.12 essential patch if required...
 
I don't have xcpm_cpu_info but do have cpuidset

thanks

Ups my mistake.. yes i meant the cpu_id_set KernelToPatch entry, sorry!
 
Status
Not open for further replies.
Back
Top