Jump to content

Guide for Installing OS X on Lenovo IdeaPad Y510p


1,428 posts in this topic

Recommended Posts

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!

 

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
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?

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.

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)

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

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? 

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.

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.

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.

 

intruder16thank 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.

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.

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

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.

 ....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.

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. 

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.

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.

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.

×
×
  • Create New...