VerizonLover Posted November 5, 2011 Share Posted November 5, 2011 EDIT: Fixed the DSDT error by changing Acquire(MUTE, 0x3e8) to Acquire(MUTE, 0xffff) However, in the SSDT, I'm still getting the following error: Object not found or not accessible from scope (_PR_.P001)Forward references from Scope operator not allowed (_PR_.P001) And the offending line is: Scope (\_PR_.P001) Those kind of errors continue up to "_PR_.P016". How do I fix that error? Link to comment Share on other sites More sharing options...
LatinMcG Posted November 5, 2011 Share Posted November 5, 2011 post dsdt in .zip Link to comment Share on other sites More sharing options...
VerizonLover Posted November 5, 2011 Author Share Posted November 5, 2011 Here's the zip. The SSDT is integrated into the DSDT (I used the "/da" option of iasl). SSDT gave errors otherwise. DSDT.zip Link to comment Share on other sites More sharing options...
VerizonLover Posted November 5, 2011 Author Share Posted November 5, 2011 Attached is a new DSDT with the following patches applied, in listed order (from DSDT Patcher for Wndows/Linux, latest revision): DTG IRQs LAN0 LPC ICH10 LPC NEHALEM Mac devices Possible operator timeout is ignored New HPET HDEF SBUS Are those the right patches, or what changes should I make? Link to comment Share on other sites More sharing options...
LatinMcG Posted November 5, 2011 Share Posted November 5, 2011 for what chipset . laptop or desktop ? (details) Link to comment Share on other sites More sharing options...
VerizonLover Posted November 5, 2011 Author Share Posted November 5, 2011 for what chipset . laptop or desktop ? (details) System: HP Pavilion HPE-180t Chipset: X58 Motherboard: Pegatron IPMTB-TK RAM: Micron 1066Mhz DDR3 (6x2GB) Hard Drive: Seagate 1.5TB ST31500341AS DVD-ROM Drive: HP DH16D5S DVD+RW Drive: HP DH16AAL Keyboard: Logitech MX3200 Mouse: Logitech MX610 Network: Intel 82567V-2 Video: MSI N220GT 1GB Audio: Integrated Realtek 888S Video Capture: Hauppauge WinTV HVR-1290 Webcam: Logitech Quickcam Pro 9000 UPS: APC Back-UPS Pro RS 1500 Link to comment Share on other sites More sharing options...
Gringo Vermelho Posted November 5, 2011 Share Posted November 5, 2011 Attached is a new DSDT with the following patches applied Your post doesn't have any attachments. Are those the right patches, or what changes should I make? That depends on what problem you're trying to solve. If you don't know, then you are blindly patching your DSDT with automated tools for no reason, and that's a bad idea. I see two patches to the LPC device. Are you sure you need both? Are you sure they don't cancel each other out, or conflict somehow? ICH10R needs a LPC device ID patch to get AppleLPC.kext loaded, ICH10 (non-R) does not need it. http://www.projectosx.com/forum/index.php?...post&p=2532 Link to comment Share on other sites More sharing options...
VerizonLover Posted November 6, 2011 Author Share Posted November 6, 2011 Patched DSDT attached with the patches I listed above patched in the order listed. dsdt_2.zip Link to comment Share on other sites More sharing options...
LatinMcG Posted November 9, 2011 Share Posted November 9, 2011 remove Alias Scope (_PR) { Processor (P001, 0x01, 0x00000810, 0x06) { } Alias (P001, CPU1) //delete this line Processor (P002, 0x02, 0x00000000, 0x00) { } Alias (P002, CPU2) //delete this line Processor (P003, 0x03, 0x00000000, 0x00) { } Alias (P003, CPU3) //delete this line Processor (P004, 0x04, 0x00000000, 0x00) { } Alias (P004, CPU4) //delete this line Processor (P005, 0x05, 0x00000000, 0x00) { } Alias (P005, CPU5) //delete this line Processor (P006, 0x06, 0x00000000, 0x00) { } Alias (P006, CPU6) //delete this line Processor (P007, 0x07, 0x00000000, 0x00) { } Alias (P007, CPU7) //delete this line Processor (P008, 0x08, 0x00000000, 0x00) { } Alias (P008, CPU8) //delete this line Processor (P009, 0x09, 0x00000000, 0x00) { } Alias (P009, CPU9) //delete this line Processor (P010, 0x0A, 0x00000000, 0x00) { } Processor (P011, 0x0B, 0x00000000, 0x00) { } Processor (P012, 0x0C, 0x00000000, 0x00) { } Processor (P013, 0x0D, 0x00000000, 0x00) { } Processor (P014, 0x0E, 0x00000000, 0x00) { } Processor (P015, 0x0F, 0x00000000, 0x00) { } Processor (P016, 0x10, 0x00000000, 0x00) { } } and OSID can go Darwin If (_OSI ("Windows 2006")) { Store (0x15, Local0) } change to If (_OSI ("Darwin")) { Store (0x15, Local0) } Link to comment Share on other sites More sharing options...
Gringo Vermelho Posted November 9, 2011 Share Posted November 9, 2011 In my experience, if you're using Chameleon with GeneratePStates and GenerateCStates=y, any modification to the processor declarations (including deleting aliases) is likely to cause native CPU power management to stop working. Link to comment Share on other sites More sharing options...
LatinMcG Posted November 9, 2011 Share Posted November 9, 2011 oki .. didnt know that.. all i see is to remove CPU Alias for asus for yrs. however i think its cause SSDT is looking for CPU1-8 ? Link to comment Share on other sites More sharing options...
Gringo Vermelho Posted November 9, 2011 Share Posted November 9, 2011 This was an issue on ASUS boards for a brief period during late versions of 10.5, but as of this version of Chameleon 2.0 RC5 it is no longer necessary to remove CPU aliases (or use a patched BIOS). You're right, the aliases are referred in the SSDT tables and that's why CPUPM stops working if you take them out. Link to comment Share on other sites More sharing options...
LatinMcG Posted November 9, 2011 Share Posted November 9, 2011 so rename P001 to CPU1 ? then delete Alias ? Link to comment Share on other sites More sharing options...
Gringo Vermelho Posted November 9, 2011 Share Posted November 9, 2011 No. The DSDT table processor declarations are referenced in the SSDT tables, messing with them (renaming, deleting aliases) will break native CPU power management.Unless you (this is a lot of work for absolutely no benefit, I've been down this road):Dump your SSDT tablesChange all instances of P00X to CPUX and all references to the CPU aliases in the SSDT tables accordinglyName the SSDT tables as instructed in the Chameleon topic I linked to earlierPlace them in /ExtraSet DropSSDT=y in org.chameleon.Boot.plistBut there really is no reason to do anything to the processor scope or the SSDT tables. P00x works just as well as CPUx on OS X and aliases are not an issue anymore.With time I have found it to be more challenging and rewarding to see how little I can modify to get OS X working well, instead of chasing every single possible hack and modification. I put that behind me after having successfully ported Master Chief's P5K Pro DSDT to my P5Q-E. I've never been to war and returned home safely but I guess it must feel a little like I felt at the time.Thanks to the state of Chameleon, today I can boot and install 10.6.3 on my hardware (P45/ICH10R/Core 2 Duo) using only fakesmc.kext in /Extra! This is impressive and amazing to me considering the hoops we used to have to jump through just a year or two ago. Link to comment Share on other sites More sharing options...
VerizonLover Posted November 9, 2011 Author Share Posted November 9, 2011 Does the attached DSDT fix it? DSDT_new2.zip Link to comment Share on other sites More sharing options...
Gringo Vermelho Posted November 9, 2011 Share Posted November 9, 2011 You can easily test it yourself without compromising anything, keep your existing DSDT.aml in /Extra and name the new one test.aml. When booting, type DSDT=test.aml at the boot prompt. Install and run IORegistryExplorer from Apple Dev Tools to see if your changes have taken effect. Link to comment Share on other sites More sharing options...
Recommended Posts