- Joined
- Jul 13, 2012
- Messages
- 49
- Motherboard
- Mac OS X 10.10
- CPU
- Core2Quad Q6600
- Graphics
- NVIDIA GT740
Attached.Need ioreg and EFI/Clover (as zip, no themes).
Attached.Need ioreg and EFI/Clover (as zip, no themes).
Attached.
// Disabling XWAK
DefinitionBlock("", "SSDT", 2, "hack", "XWAK", 0)
{
External(_SB.PCI0.XHC, DeviceObj)
// In DSDT, native XWAK is renamed ZWAK
// As a result, calls to it land here.
Method(_SB.PCI0.XHC.XWAK)
{
// do nothing
}
}
//EOF
// Disabling XSEL
DefinitionBlock("", "SSDT", 2, "hack", "XSEL", 0)
{
External(_SB.PCI0.XHC, DeviceObj)
// In DSDT, native XSEL is renamed ZSEL
// As a result, calls to it land here.
Method(_SB.PCI0.XHC.XSEL)
{
// do nothing
}
}
//EOF
I thought about that, and actually made that edit yesterday, but that didn't fix the issue. I ran it again just now copy-pasting what you wrote just to be sure. Here's the updated ioreg and the resulting aml file. CLOVER is unchanged, save for the updated aml.Oops...
I thought about that, and actually made that edit yesterday, but that didn't fix the issue. I ran it again just now copy-pasting what you wrote just to be sure. Here's the updated ioreg and the resulting aml file. CLOVER is unchanged, save for the updated aml.
Sadly, no change with nullified XSEL, either. I added the XSEL code to the SSDT-XWAK.dsl.Read post #74 (eg. try nullifying XSEL).
My turn for OOPS! That was a failed attempt at trying solve my own problems, and perhaps learn a bit more about DSDT/SSDT editing. I thought I had reverted all of those changes.Note: The code you have in SSDT-HACK-G2-lid is wrong. It conflicts with Device(LID) already in DSDT.
Sadly, no change with nullified XSEL, either. I added the XSEL code to the SSDT-XWAK.dsl.
My turn for OOPS! That was a failed attempt at trying solve my own problems, and perhaps learn a bit more about DSDT/SSDT editing. I thought I had reverted all of those changes.
Updated clover and ioreg attached.
if [ -d ~/Downloads/RehabMan ]; then rm -R ~/Downloads/RehabMan; fi
mkdir ~/Downloads/RehabMan
cd ~/Downloads/RehabMan
patchmatic -extract
I tried mapping XSEL to ESEL with the following patch to no effect:SSDT-XSEL.aml is not present in ACPI/patched. ??
You might try the same idea with ESEL (maybe you see the pattern now).
You could also try simulating "Windows 2012"... (XOSI).
Comment: Change Method(XSEL, 0, S) to ESEL
Find: <5853454c 08>
Replace: <4553454c 08>
Comment: Change Method(ESEL, 0, S) to ZSEL
Find: <4553454c 08>
Replace: <5a53454c 08>
Download patchmatic: https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads/RehabMan-patchmatic-2015-0107.zip
Extract the 'patchmatic' binary from the ZIP. Copy it to /usr/bin, such that you have the binary at /usr/bin/patchmatic.
In terminal,
Code:if [ -d ~/Downloads/RehabMan ]; then rm -R ~/Downloads/RehabMan; fi mkdir ~/Downloads/RehabMan cd ~/Downloads/RehabMan patchmatic -extract
Note: It is easier if you use copy/paste instead of typing the commands manually.
Post contents of Downloads/RehabMan directory (as ZIP).
I tried mapping XSEL to ESEL with the following patch to no effect:
Code:Comment: Change Method(XSEL, 0, S) to ESEL Find: <5853454c 08> Replace: <4553454c 08>
This patch made the machine unbootable. I also tried patching ESEL to ZSEL with the following patch (which I don't think you were suggesting, but what the hell), and it also made the machine unbootable.
Code:Comment: Change Method(ESEL, 0, S) to ZSEL Find: <4553454c 08> Replace: <5a53454c 08>
You can't change XSEL and ESEL both to ZSEL. One would have to become YSEL (method names in the same scope must be unique). If you changed both to ZSEL, it would likely cause a KP (DSDT would be invalid with duplicate methods names). We can get away with _WAK->ZWAK and XWAK->ZWAK as these methods reside in a separate scope.
But yes...the idea is to rename XSEL and ESEL (and XWAK) such that they do nothing... And then you'll need to provide an ESEL in an SSDT (in correct scope), so the calls to it don't cause ACPI abort...
Armed with new knowledge, give it another try...
The idea is to make sure that DSDT is not changing PR2 (controls USB2 port routing from XHCI) on wake from sleep. It is starting to seem like it is some other problem with the cam, but the only way to test is to nullify the effects of XSEL and ESEL (your DSDT calls ESEL when less than "Windows 2012", which is why also the experiments with XOSI).
You should also check in system.log for any clues regarding USB and the camera...
Finally, some devices work better when they are on EHCI, so that is also something to try. Remove the code related to disabling EHCI in SSDT-USB-8x0s-G2.aml and change the XHC _DSM to not inject RM,pr2-force (you can just remove that entire section, leaving only the port definitions). By doing that FakePCIID_XHCIMux will route USB2 devices (such as the webcam) to EHCI. You may need custom config for the EHCI port/hub at that point...
$ sudo touch /System/Library/Extensions/ && sudo kextcache -u /
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext JMB38X.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext IntelMausiEthernet.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_XHCIMux.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_Intel_HDMI_Audio.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_Intel_HD_Graphics.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_Broadcom_WiFi.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext BrcmPatchRAM2.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext BrcmFirmwareRepo.kext
kext-dev-mode allowing invalid signature -67030 0xFFFFFFFFFFFEFA2A for kext AppleHDA_ProBook.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ACPIDebug.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext USBInjectAll.kext
First, I CLOVER-patched ESEL->YESEL and XSEL->ZSEL to no effect.
but the ports kept getting mapped to XHC anyway until I installed FakePCIID_XHCIMux.kext.
After that, the ports remained on the EHC1 bus, but the webcam still didn't wake.