Jump to content
469 posts in this topic

Recommended Posts

You could try a few more DSDT patches from my repo:

"7-series USB"

"7-series USB3 multiplex" (if its compatible; note: not designed for GenericUSBXHCI)

 

And there's more related to sleep (_WAK fixes, IRQ fixes, SMBUS, etc, etc)

I've patched my DSDT using 7-series patch from your repo, also _WAK v2, IRQ and SMBUS, and removed GenericUSBXHCI kext and -gux_defer_usb2.

Console returns

EHC1 EHC2 XHC1
I forgot to mention... I'm booting MacOSx from an external HDD attached to a USB port. I guess this is keeping me from sleep?..

 

It probably included a rollback of AppleACPIPlatform (or your DSDT did not require battery patches). What is the output of:

kextstat|grep -y acpiplatform

 

Yes, I'm using a rollback of AppleACPIPlatform (10.8.5)

Terminal returns

useletterss-MacBook-Pro:~ useletters$ kextstat|grep -y acpiplatform
   12    2 0xffffff7f81bc5000 0x60000    0x60000    com.apple.driver.AppleACPIPlatform (1.8) <11 10 7 6 5 4 3 1>

You should get idle at x8. Your SSDT is probably wrong for your CPU.

How can I generated the correct SSDT? My CPU is I7-4700MQ, same as your laptop.. Also, the script returns the correct CPU model.. Should I use different frequency in running the script? Also, my system halts, as what I was talking about, when there is an external display attached on HDMI port. I've just experienced it. The scenario was, I was watching a video from youtube, around 4 more tabs opened on Chrome, and Mail is opened. Then suddenly, the halt occurs, I couldn't click anything. My cursor is in loading state. Though my clock still updates (I can see the seconds increments)

Hey Rehabman, just curious... Does ssdtprgen support C2Duo Processor?

No.

I've patched my DSDT using 7-series patch from your repo, also _WAK v2, IRQ and SMBUS, and removed GenericUSBXHCI kext and -gux_defer_usb2.

Console returns

EHC1 EHC2 XHC1
I forgot to mention... I'm booting MacOSx from an external HDD attached to a USB port. I guess this is keeping me from sleep?..

 

It could. Installing to a USB HDD is not recommended.

 

Yes, I'm using a rollback of AppleACPIPlatform (10.8.5)

Terminal returns

useletterss-MacBook-Pro:~ useletters$ kextstat|grep -y acpiplatform
   12    2 0xffffff7f81bc5000 0x60000    0x60000    com.apple.driver.AppleACPIPlatform (1.8) <11 10 7 6 5 4 3 1>

 

Why run 10.8.5 AppleACPIPlatform with 10.9?

 

How can I generated the correct SSDT? My CPU is I7-4700MQ, same as your laptop.. Also, the script returns the correct CPU model.. Should I use different frequency in running the script? Also, my system halts, as what I was talking about, when there is an external display attached on HDMI port. I've just experienced it. The scenario was, I was watching a video from youtube, around 4 more tabs opened on Chrome, and Mail is opened. Then suddenly, the halt occurs, I couldn't click anything. My cursor is in loading state. Though my clock still updates (I can see the seconds increments)

I used Pike's ssdtPRgen script. Then made corrections because the data he has for this CPU is incorrect (I also reported the bug in his thread on tmx).

 

I haven't done much testing with HDMI.

It could. Installing to a USB HDD is not recommended.

I've turned my USB HDD into internal HDD now, still have the wake reason.

Wake reason: EHC1 EHC2 XHC1

Why run 10.8.5 AppleACPIPlatform with 10.9?

Well, I really don't know. Anyway, I've installed 10.9 AppleACPIPlatform back.

 

I used Pike's ssdtPRgen script. Then made corrections because the data he has for this CPU is incorrect (I also reported the bug in his thread on tmx).

 

I haven't done much testing with HDMI.

Yeah saw your post at tmx, though I don't know how to generate the correct SSDT. I've also used Pike's ssdtPRgen script. Could you post the command you used?

Also, how can I enable my GT750m, not ultrabay? I was able to flash my bios, and I can change my video configuration. When I try to disable Special Features (I believe this is switching), without the ultrabay GPU, there's no display on my screen, even on VGA and HDMI. The only way I can get display is to put the ultrabay GPU..

I've turned my USB HDD into internal HDD now, still have the wake reason.

Wake reason: EHC1 EHC2 XHC1
Well, I really don't know. Anyway, I've installed 10.9 AppleACPIPlatform back.

 

Did you try the USB related DSDT patches I mention. In my particular case, I needed to have AAPL,clock-id injected on EHC1/EHC2 and use GenericUSBXHCI for XHC, plus -gux_defer_usb2. Each laptop seems to vary on this kind of thing. And you should probably work on getting your Ethernet working if you haven't already.

 

Yeah saw your post at tmx, though I don't know how to generate the correct SSDT. I've also used Pike's ssdtPRgen script. Could you post the command you used?

Where you got Pike's script, there are instructions. I just used the ProBook Installer, which contains Pike's script. Then I did some edits to correct the problems resulting from the bug in the script.

 

Also, how can I enable my GT750m, not ultrabay? I was able to flash my bios, and I can change my video configuration. When I try to disable Special Features (I believe this is switching), without the ultrabay GPU, there's no display on my screen, even on VGA and HDMI. The only way I can get display is to put the ultrabay GPU..

Is your GT750 controlled via Optimus? I assume it is, so you're using HD4600. Optimus and thus your GT750m is not supported on OS X.

Did you try the USB related DSDT patches I mention. In my particular case, I needed to have AAPL,clock-id injected on EHC1/EHC2 and use GenericUSBXHCI for XHC, plus -gux_defer_usb2. Each laptop seems to vary on this kind of thing. And you should probably work on getting your Ethernet working if you haven't already.

I'll try to patch them again. Should I patch 1 by 1 and check which one works?.. I have my Ethernet working..

 

Where you got Pike's script, there are instructions. I just used the ProBook Installer, which contains Pike's script. Then I did some edits to correct the problems resulting from the bug in the script.

I got a new one from his repo. And it works now. The following are my p-states now

11/20/13, 1:13:15 PM, P States: 8, 12, 16, 20, 24, 25, 26, 27, 28, 29, 30, 32

Is your GT750 controlled via Optimus? I assume it is, so you're using HD4600. Optimus and thus your GT750m is not supported on OS X.

How can I know if it's controlled via Optimus? is this the switching functionality? How can I disable Optimus and use the onboard GT750m?

Hello...

My cpu is stock ivy i5. Is it possible to launch the script without any argument and produce a good ssdt file?

And also to put an end to my confusion, Is it "mandatory" to set GenerateP & C state to "No" if we have SSDT.aml?

 

Thanks.

I'll try to patch them again. Should I patch 1 by 1 and check which one works?.. I have my Ethernet working..

Yes, always make changes one at a time when possible, and experiment with AppleUSBXHCI vs. GenericUSBXHCI. I find there is no pattern to what works and what doesn't, probably due to not knowing enough about the problem.

 

I got a new one from his repo. And it works now. The following are my p-states now

11/20/13, 1:13:15 PM, P States: 8, 12, 16, 20, 24, 25, 26, 27, 28, 29, 30, 32

 

That looks good. I received notification from Pike today, that he corrected the data for 4700MQ.

 

How can I know if it's controlled via Optimus? is this the switching functionality? How can I disable Optimus and use the onboard GT750m?

If you have both HD4000 and the nvidia showing up on the PCI bus, then it is Optimus (nvidia's switching tech).

Hello...

My cpu is stock ivy i5. Is it possible to launch the script without any argument and produce a good ssdt file?

Usually, yes. It is always advisable to check the output of the script to be sure it makes sense. That's how I found the bug in the i7-4700MQ data, for example. Never assume that the tools are bug-free.

 

And also to put an end to my confusion, Is it "mandatory" to set GenerateP & C state to "No" if we have SSDT.aml?

You definitely do not want bootloader c/p state generation if you're using an SSDT. Also a good idea to drop OEM c/p state tables when using an SSDT. They all can provide duplicate (and conflicting) information which can lead to a KP on boot.

Yes, always make changes one at a time when possible, and experiment with AppleUSBXHCI vs. GenericUSBXHCI. I find there is no pattern to what works and what doesn't, probably due to not knowing enough about the problem.

Okay, I will try this.

 

That looks good. I received notification from Pike today, that he corrected the data for 4700MQ.

That's good to know, thanks! :D

 

If you have both HD4000 and the nvidia showing up on the PCI bus, then it is Optimus (nvidia's switching tech).

I guess so? I've attached several screenshots of my System Information.

 

EDIT:

 

So far. I've tried the patches you've said also the GenericUSBXHCI from your repo, but still same wake reason. I haven't tried AppleUSBXHCI though..

Attached is my dsdt..

post-1199894-0-17154000-1384996809_thumb.png

useletters dsdt.zip

So far. I've tried the patches you've said also the GenericUSBXHCI from your repo, but still same wake reason. I haven't tried AppleUSBXHCI though..

Attached is my dsdt..

Did you also use -gux_defer_usb2. Also be sure to use the latest GenericUSBXHCI.

 

And your DSDT seems to be compatible with the multiplex patch, so it is also something to try (to use AppleUSBXHCI instead of Generic).

Did you also use -gux_defer_usb2. Also be sure to use the latest GenericUSBXHCI.

 

And your DSDT seems to be compatible with the multiplex patch, so it is also something to try (to use AppleUSBXHCI instead of Generic).

Well.. That I forgot.. XD I'll try it in a bit.

Where can I get AppleUSBXHCI for Mavericks?

 

EDIT: SLEEP NOW WORKS! :D -gux_defer_usb2 was the answer! :D

 

Anyway, is there a way to patch AppleHDA for me?

Well.. That I forgot.. XD I'll try it in a bit.

Where can I get AppleUSBXHCI for Mavericks?

It is built-in. So, you already have it.

 

EDIT: SLEEP NOW WORKS! :D -gux_defer_usb2 was the answer! :D

Great.

 

Anyway, is there a way to patch AppleHDA for me?

There are many guides for patching AppleHDA.

Great.

Thanks! :D

 

There are many guides for patching AppleHDA.

Could you specify one?

 

Also, can I disable my integrated GPU both GT750m and Intel HD4600 then use my Ultrabay GT750m? I believe it should be detected as PCIe..

 

EDIT:

 

And, which wireless card should I buy that would work out of the box? Theoretically, any wireless card should work as my bios is unlocked, right?

Thanks! :D

 

Could you specify one?

Not really. Use google.

 

Also, can I disable my integrated GPU both GT750m and Intel HD4600 then use my Ultrabay GT750m? I believe it should be detected as PCIe..

I don't have much experience with discrete cards, so I'm not sure. You could try and let us know (probably in a different thread, since this is getting quite off-topic).

Have you checked out Pike's blog post from today?

 

Very VERY relevant.

 

You can use mach_kernel (vanilla) with a tiny bit of hex editing to solve the reboot issue

Have you checked out Pike's blog post from today?

 

Very VERY relevant.

 

You can use mach_kernel (vanilla) with a tiny bit of hex editing to solve the reboot issue

Have you verified that, or is that just an assumption?

 

I ask because my prior attempts to get 10.9 running on this machine involved filtering out the 0xe2 MSR writes from that exact section of code (I came up with a fairly elaborate set of patches). And it did not work. Now, I have not attempted to filter *all* MSR writes resulting from that code as pike proposes, but I could certainly give that a try.

Have you verified that, or is that just an assumption?

 

I ask because my prior attempts to get 10.9 running on this machine involved filtering out the 0xe2 MSR writes from that exact section of code (I came up with a fairly elaborate set of patches). And it did not work. Now, I have not attempted to filter *all* MSR writes resulting from that code as pike proposes, but I could certainly give that a try.

 

Cant verify it.

 

Hex hacking isn't my cup-o-tea

Cant verify it.

 

Hex hacking isn't my cup-o-tea

I have verified it (and posted a comment with additional information on Pike's blog).

 

Edit: Not so fast. I patched a different section of code (misread Pike's blog). I'll have to try his later (I think it will not work).

 

Hopefully someone else can verify besides me. If you want to try, there is a perl patch I wrote in the comments section on Pike's blog. perl patches are pretty easy to use...

That gives me an idea

 

Lets see if the Clover guys can come up with something....

Perl patch (for my solution, is not the same patch as Pike proposed):

 

perl -pi -e ‘s|\x0f\x30(\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce\x75)|\x90\x90${1}|g’ mach_kernel
Clover patch would be search for:

0f308b4fd80f3289c048c1e2204809c24889174883c730ffce75
replace with:

90908b4fd80f3289c048c1e2204809c24889174883c730ffce75
I still think it is possible to come up with a "better" patch (one that doesn't eliminate all MSR writes in this code).

 

Stay tuned...

Perl patch (for my solution, is not the same patch as Pike proposed):

 

perl -pi -e ‘s|\x0f\x30(\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce\x75)|\x90\x90${1}|g’ mach_kernel
Clover patch would be search for:

0f308b4fd80f3289c048c1e2204809c24889174883c730ffce75
replace with:

90908b4fd80f3289c048c1e2204809c24889174883c730ffce75
I still think it is possible to come up with a "better" patch (one that doesn't eliminate all MSR writes in this code).

 

Stay tuned...

 

 

IMO a bootloader solution is much cleaner over direct patching.

 

Everytime you get a new kernel you need to patch it again, making sure that you have to go through a lot of steps to get it back.

 

A bootloader solution would prevent that.

 

Clover's Kext patching is awesome. I have TRIM enabled. Updates don't matter, it will always be on.

IMO a bootloader solution is much cleaner over direct patching.

 

Everytime you get a new kernel you need to patch it again, making sure that you have to go through a lot of steps to get it back.

 

A bootloader solution would prevent that.

 

Clover's Kext patching is awesome. I have TRIM enabled. Updates don't matter, it will always be on.

Yes, of course.

 

But first you must have a good idea as to what you want to do in the patch. Even binary patches like this can break with future releases of the kernel (code can be rearranged by the developer or compiler).

 

Clover's kext patching is useful in many, but not all, scenarios. Because it does not have a full regex engine, the kind of patches you can do are limited to simple search and replace with simple static patterns. You can do much more with regular expressions. This patch, as written does not require regex.

Hi RehabMan, I follow this topic from early beginning. Thanks for your work. Patched kernel is only way to run OSX on Toshiba P50-A with Haswell (i7-4700MQ). I use MacBookAir6,1 smbios in Clover and c/p states generating (score in geekbench 3 x64 ~11200).

 

I wrote about binpatch in Clover topic on projectosx. I hope you don't mind. It would be great if this can be implemented in Clover kernelpatcher.

 

Once again, thank you and Pike for this solution.

 

EDIT: I use DSDT to inject LPC ID (8086:8c4b - HM87, original is 8086:8c49 - not present in AppleLPC.kext) to load AppleLPC.

Hi RehabMan, I follow this topic from early beginning. Thanks for your work. Patched kernel is only way to run OSX on Toshiba P50-A with Haswell (i7-4700MQ). I use MacBookAir6,1 smbios in Clover and c/p states generating (score in geekbench 3 x64 ~11200).

 

I wrote about binpatch in Clover topic on projectosx. I hope you don't mind. It would be great if this can be implemented in Clover kernelpatcher.

 

Once again, thank you and Pike for this solution.

 

EDIT: I use DSDT to inject LPC ID (8086:8c4b - HM87, original is 8086:8c49 - not present in AppleLPC.kext) to load AppleLPC.

Keep in mind it is still a work-in-progress. I've already published a "better" patch on my blog. But I've got more work to do.

 

FYI: No need to inject LPC, as 8086:8c4b is natively recognized.

×
×
  • Create New...