ahmed_ais Posted April 6, 2015 Author Share Posted April 6, 2015 C'mon guys it's not that bad .. I too bought my BCM4352 from China (through ebay though). I put the order on 12 September and the item arrived on 20 September so 8 days are not that long! 1 Link to comment Share on other sites More sharing options...
brutalMac Posted April 6, 2015 Share Posted April 6, 2015 I think it depends on a country where are you living. I live in Belarus. Our customs is a sluthouse, packages arrive normally 60 - 90 days from China) Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 6, 2015 Author Share Posted April 6, 2015 OK I'm in the UK which is further away from China than Belarus. But yes it may be a problem with customs as you mentioed, hope it don't get delayed much for you guys. Link to comment Share on other sites More sharing options...
intruder16 Posted April 6, 2015 Share Posted April 6, 2015 @brutalMac: AppleHDA issue resolved? Link to comment Share on other sites More sharing options...
brutalMac Posted April 6, 2015 Share Posted April 6, 2015 @brutalMac: AppleHDA issue resolved? I'll take a look at this at home later. 'Cause it's not critical for me. I'm just interested in to know what's a problem actually) Link to comment Share on other sites More sharing options...
brutalMac Posted April 6, 2015 Share Posted April 6, 2015 Something new with solving AppleHDA problem) I've updated clover to 3193) changed my config.plist) but no luck) but i think i'm getting closer to a problem, found something interesting in console: 4/6/15 11:54:07.000 PM kernel[0]: Sound assertion in AppleHDAController at line 1400 4/6/15 11:54:07.330 PM com.apple.kextd[19]: kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/DummyHDA.kext" 4/6/15 11:54:07.332 PM com.apple.kextd[19]: Can't load /System/Library/Extensions/DummyHDA.kext - no code for running kernel's architecture. 4/6/15 11:54:07.333 PM com.apple.kextd[19]: Load com.apple.driver.AppleHDA failed; removing personalities from kernel. Do I need to add something important in DSDT? I have patched DSDT only with intruder16's auto-patcher. P.S. Anyway thank you guys (especially intruder16 and ahmed_ais) for this great work! Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 6, 2015 Author Share Posted April 6, 2015 Something new with solving AppleHDA problem) I've updated clover to 3193) changed my config.plist) but no luck) but i think i'm getting closer to a problem, found something interesting in console: 4/6/15 11:54:07.000 PM kernel[0]: Sound assertion in AppleHDAController at line 1400 4/6/15 11:54:07.330 PM com.apple.kextd[19]: kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/DummyHDA.kext" 4/6/15 11:54:07.332 PM com.apple.kextd[19]: Can't load /System/Library/Extensions/DummyHDA.kext - no code for running kernel's architecture. 4/6/15 11:54:07.333 PM com.apple.kextd[19]: Load com.apple.driver.AppleHDA failed; removing personalities from kernel. Okay this is weird! All Kexts are supposed to be 64-bit now and this error should not appear. I suspect the DummyHDA.kext you are using so post back the output of this command in Terminal: kextfind -not -arch x86_64 Link to comment Share on other sites More sharing options...
brutalMac Posted April 6, 2015 Share Posted April 6, 2015 GeForceTesla.kext has no Info.plist file. IOBluetoothHostControllerUARTTransport.kext has no Info.plist file. NVDANV50HalTesla.kext has no Info.plist file. NVDAResmanTesla.kext has no Info.plist file. /System/Library/Extensions/DummyHDA.kext this is the output. Do you mean to say that DummyHDA that I have is not a 64-bit kext? Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 6, 2015 Author Share Posted April 6, 2015 For some reason this is what your OS X can see now. It doesn't see DummyHDA.kext as 64-bit so the kernel will not load it. As a consequence, the AppleHDA.kext will not load either. Re-download DummyHDA.kext, install it correctly, fix permissions and clear cache. Link to comment Share on other sites More sharing options...
brutalMac Posted April 7, 2015 Share Posted April 7, 2015 For some reason this is what your OS X can see now. It doesn't see DummyHDA.kext as 64-bit so the kernel will not load it. As a consequence, the AppleHDA.kext will not load either. Re-download DummyHDA.kext, install it correctly, fix permissions and clear cache. I've re-downloaded all 3 kexts, reinstalled, fixed permissions and cleared cache) the same result and output in console) Link to comment Share on other sites More sharing options...
intruder16 Posted April 7, 2015 Share Posted April 7, 2015 4/6/15 11:54:07.000 PM kernel[0]: Sound assertion in AppleHDAController at line 1400 That is interesting. I used to get that lot when i was trying to fix AppleHDA. I don't actually remember how i fixed it. .....Do I need to add something important in DSDT? I have patched DSDT only with intruder16's auto-patcher..... No. As of now, almost everything is fixed. Currently i'm trying to fix USB2.0 (AppleUSBEHCI drivers should attach to USB2 devices but instead AppleUSBXHCI does), and 'll update here as soon as its fixed. Look here for more info. Something new with solving AppleHDA problem) I've updated clover to 3193) changed my config.plist) but no luck) but i think i'm getting closer to a problem..... I assume you are correctly injecting Audio Layout ID from Clover which is "3". Remove AppleHDA.kext, DummyHDA.kext & EAPDFix.kext Install only AppleHDA.kext from attachment. (Only for English Locale, stripped all others) Reboot twice. AppleHDA.kext.zip Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 7, 2015 Author Share Posted April 7, 2015 No. As of now, almost everything is fixed. Currently i'm trying to fix USB2.0 (AppleUSBEHCI drivers should attach to USB2 devices but instead AppleUSBXHCI does), and 'll update here as soon as its fixed. Look here for more info. I toke a look over that thread, big things are going on there! Keep up the good work, it is getting better day after day. Another thing, I don't know if Ethernet is working or not. I used to utilize a patched kext but I never got to test the whole thing as I only use WiFi so I doubt is even working. Would you kindly attach the native one and comment whether Ethernet is working or not? Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 7, 2015 Author Share Posted April 7, 2015 Guide updated. Change-log: 07/04/2015 Updated downloads section with new link for FakeSMC.kext. Added a section to fix FakeSMC.kext to get rid of the entry: powerd[27]: Failed to read current rating(0xe00002f0) that appears in log every 30 seconds. Link to comment Share on other sites More sharing options...
brutalMac Posted April 7, 2015 Share Posted April 7, 2015 intruder16, thank you, now it works)))) now I have only AppleHDA.kext in S/L/E and if i understand correctly without Dummy kext I will have to keep and reinstall this AppleHDA.kext after every system update. Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 7, 2015 Author Share Posted April 7, 2015 intruder16, [/size]thank you, now it works)))) now I have only AppleHDA.kext in S/L/E and if i understand correctly without Dummy kext I will have to keep and reinstall this AppleHDA.kext after every system update. First congrats for having it working. However, I think this is just temporary step intruder16 recommended so he can advice you what to do next to activate native AppleHDA. The way you have it means after every update you will need NEW patched AppleHDA or patch it your self. It is not a good practice to use older kext with newer system version. Actually the older kext may not even work on newer system. Link to comment Share on other sites More sharing options...
intruder16 Posted April 7, 2015 Share Posted April 7, 2015 I toke a look over that thread, big things are going on there! Keep up the good work, it is getting better day after day. Another thing, I don't know if Ethernet is working or not. I used to utilize a patched kext but I never got to test the whole thing as I only use WiFi so I doubt is even working. Would you kindly attach the native one and comment whether Ethernet is working or not? Sadly i don't know what more to do. In Linux as well as windows, the USB2.0 port is attached to XHCI driver which btw should not happen (should be EHCI). This means that the settings for USB to route USB 2.0 devices from XHCI to EHCI is controlled by BIOS (i believe) and i've changed almost every setting in my BIOS related to USB and the only setting that seems to work is to disable XHCI entirely which is not recommended since it'll disable USB3.0 speeds. It'll be great if anybody having original windows installed (default that came with laptop) to check if USB2 devices are attached to EHCI. You can see that using "USB Tree View". Also if you can tell the manufacturer of USB drivers (Intel or Microsoft). I'll greatly appreciate it. Thanks. Also it is not needed to fix this, the native AppleUSB driver works great anyway (Recommended, avoid using GenericUSB kext) Ethernet is working great. I just tried it (using internet connection from LAN as i write this post). I did not notice this before that you did not mention any fix for ethernet in OP. Sorry for this as i've been following myself from the beginning. The ethernet kext you can find here. All credits to the developer. Guide updated. Change-log: 07/04/2015 Updated downloads section with new link for FakeSMC.kext. Added a section to fix FakeSMC.kext to get rid of the entry: powerd[27]: Failed to read current rating(0xe00002f0) that appears in log every 30 seconds. No need to do this. A fixed version of FakeSMC is already uploaded by RehabMan here. Don't forget to check other kexts provided by him like FakePCIID. intruder16, thank you, now it works)))) now I have only AppleHDA.kext in S/L/E and if i understand correctly without Dummy kext I will have to keep and reinstall this AppleHDA.kext after every system update. Glad to know its working. Correct. For update safe method this will help. First congrats for having it working. However, I think this is just temporary step intruder16 recommended so he can advice you what to do next to activate native AppleHDA. The way you have it means after every update you will need NEW patched AppleHDA or patch it your self. It is not a good practice to use older kext with newer system version. Actually the older kext may not even work on newer system. See post above. Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 7, 2015 Author Share Posted April 7, 2015 Ethernet is working great. I just tried it (using internet connection from LAN as i write this post). I did not notice this before that you did not mention any fix for ethernet in OP. Sorry for this as i've been following myself from the beginning. The ethernet kext you can find here. All credits to the developer. Yea thanks. But still I need the original IONetworkingFamily.kext because I removed mine due to confliction with the patched one. Never mind, I found a backup (backing things up is a bless!) No need to do this. A fixed version of FakeSMC is already uploaded by RehabMan here. Don't forget to check other kexts provided by him like FakePCIID. Good, at least we now know the reason behind such problem. I will update the guide accordingly. Glad to know its working. Correct. For update safe method this will help. See post above. This will return him to initial problem with DummyHDA.kext not loaded. I know it is the right thing to do which is what I'm doing myself but for some reason it is not working for him. Something is wrong with his setup preventing the update-safe method to work as intended. Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 7, 2015 Author Share Posted April 7, 2015 Guide updated again overriding last update. Change-log: 07/04/2015 Replaced FakeSMC.kext with Rehabman's version which includes a fix for the powerd[27]: Failed to read current rating(0xe00002f0) issue. Removed both Audio fixes VooodooHDA and non-update-safe patched AppleHDA, only the update-safe AppleHDA patch remains. Removed VoodooHDA and Patched AppleHDA.kext Links from downloads section. Removed boot glitch fix for Yosemite versions before 10.10.2, most of us are on latest version anyway. Removed nv_disable=1 boot-arg, not needed with Nvidia cards are disabled by other means. Removed -gux_defer_usb2 boot-arg, not needed while GenericUSBXHCI USB 3.0 Driver is not in use. Replaced manual BCM4352 patches with Fake-PCI-ID method + Clover patch (still not update safe). Modified SMBIOS setting for Installation section. Added section to fix Ethernet (LAN). Removed Fixing Home and End Keys using KeyBindings, not needed anymore I guess. Added BrcmPatchRAM method to bluetooth fix section and downloads Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 8, 2015 Author Share Posted April 8, 2015 Sadly i don't know what more to do. In Linux as well as windows, the USB2.0 port is attached to XHCI driver which btw should not happen (should be EHCI). This means that the settings for USB to route USB 2.0 devices from XHCI to EHCI is controlled by BIOS (i believe) ... I'm not sure what you are trying to achieve here. I surveyed the XHCI and I quote from Wikipedia: Extensible Host Controller Interface (XHCI) is the newest host controller standard that improves speed, power efficiency and virtualization over its predecessors The goal was also to define a USB host controller to replace UHCI/OHCI/EHCI. It supports all USB device speeds (USB 3.1 SuperSpeed+, USB 3.0 SuperSpeed, USB 2.0 Low-, Full-, and High-speed, USB 1.1 Low- and Full-speed). Therefor, from my understanding, the USB 2.0 ports should be attached to XHCI controller as long as it is implemented. I also understand it should be awkward to find USB 3.0 ports attached to XHCI while USB 2.0 ports are attached to EHCI. ... and the only setting that seems to work is to disable XHCI entirely which is not recommended since it'll disable USB3.0 speeds. Nothing unexpected here. If XHCI is implemented and enabled > USB 3.0 and USB 2.0 ports each works on its designed speed through XHCI. If XHCI is not implemented or disabled > USB 3.0 works with the maximum speed of USB 2.0 through EHCI. I don't have the OEM copy of Windows that was pre-installed. But I do use the original BIOS (which you believe is responsible for routing the ports to controllers) and I have all my visible USB ports attached to XHCI which have a driver manufactured by Microsoft. Link to comment Share on other sites More sharing options...
intruder16 Posted April 8, 2015 Share Posted April 8, 2015 ....Therefor, from my understanding, the USB 2.0 ports should be attached to XHCI controller as long as it is implemented..... Look here. The XHCI driver stack is supposed to handoff USB2.0 devices to EHCI controller for better support. There are many reason's one would want this to happen. For some USB audio systems you do not want to attach them to XHCi because they won't work with XHCI. In my case, USB WiFi does not work well with XHCI drivers (Kernel panic and USB shut down if i remove it or try to turn it off, sleep issues, etc etc). It should be controlled by EHCI stack for proper functioning. Simply stated, USB2.0 port and controller should use EHCI to function correctly. You can find many threads regarding this in google. ...I also understand it should be awkward to find USB 3.0 ports attached to XHCI while USB 2.0 ports are attached to EHCI..... Can you explain why would you find it awkward? This is the Intel 8-series datasheet. Go to chapter 16.1.36/37 (page 593). There is a reason why the switch between xHC and EHC is explained in there. Also, FYI "gux_defer_usb2" boot flag does the same. ....Nothing unexpected here. If XHCI is implemented and enabled > USB 3.0 and USB 2.0 ports each works on its designed speed through XHCI. If XHCI is not implemented or disabled > USB 3.0 works with the maximum speed of USB 2.0 through EHCI.... Of course. I'm fully aware of that. ....I don't have the OEM copy of Windows that was pre-installed. But I do use the original BIOS (which you believe is responsible for routing the ports to controllers) and I have all my visible USB ports attached to XHCI which have a driver manufactured by Microsoft.... The original BIOS has this setting to use XHCI by default in Smart-Auto mode. Here for more info. I updated my BIOS to v3.08 still nothing. So i'm back to unlocked 3.05. Also, as i said before, its not needed to fix this. But i need it to be fixed for my purpose. Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 8, 2015 Author Share Posted April 8, 2015 I think I have been mistaken. I toke a look on the links you attached and also read this blog post and it changed my understandings. So I do believe that any device connected to USB 3.0 port will be managed by xHCI (without porting even if it is USB 2.0 device according to Microsoft guidelines). However a device connected through USB 2.0 port will only be managed by EHCI. This leaves a question why do our USB 2.0 port routes to xHCI while it should not according to Microsoft? If this is your question from the start, I second it. Link to comment Share on other sites More sharing options...
intruder16 Posted April 8, 2015 Share Posted April 8, 2015 I think I have been mistaken. I toke a look on the links you attached and also read this blog post and it changed my understandings. So I do believe that any device connected to USB 3.0 port will be managed by xHCI (without porting even if it is USB 2.0 device according to Microsoft guidelines). However a device connected through USB 2.0 port will only be managed by EHCI. This leaves a question why do our USB 2.0 port routes to xHCI while it should not according to Microsoft? If this is your question from the start, I second it. Correct. XHCI driver will handoff to EHCI when USB2.0/3.0 devices is connected to USB2.0 port. But that's not the case here. That's why i was investigating it. Link to comment Share on other sites More sharing options...
brutalMac Posted April 8, 2015 Share Posted April 8, 2015 I've just updated to 10.10.3) Sound stopped working as I expected and I'm going to re-download original unpatched AppleHDA and Dummy kexts. Anyway, all other things is working like before without any efforts. Link to comment Share on other sites More sharing options...
intruder16 Posted April 8, 2015 Share Posted April 8, 2015 I've just updated to 10.10.3) Sound stopped working as I expected and I'm going to re-download original unpatched AppleHDA and Dummy kexts. Anyway, all other things is working like before without any efforts. Thanks for the feedback. I'll update the AppleHDA kext tomorrow. Until then you can try DummyHDA.kext. Its good to know that everything's working great. After using it for some time, if anything seems different or not working please let me know. Link to comment Share on other sites More sharing options...
ahmed_ais Posted April 8, 2015 Author Share Posted April 8, 2015 Same here. Initial impression: Everything works in 10.10.3 the same way as in 10.10.2 (including Audio as expected, TRIM, QE/CI, BCM4352 working with 5GHz).All good! A side note: While I don't have any problem with power management after update, but I think it is good idea for anyone to re-generate CPUPM SSDT after the update. Link to comment Share on other sites More sharing options...
Recommended Posts