blackosx

Thanks for posting your ioreg dumps, however I can't open them! And it's not you as I can't open my own ones that I've made with the v3 of IORegistryExplorer that I posted for you.. It's either a damaged version of it's just really buggy! So I was going to ask you to do it again, but maybe there's no need right now.... because.....looking at the differences in your Linux ACPI dumps compared to mine: - Your dumps are missing SSDT_PmRef_P001Cst.dsl which are the native C-States. Did you find out more about why your C-State options are missing from your BIOS? So for now, the way I see it is this.... As you've already had success using the auto-generated P/C state boot options on Chameleon, then maybe stick to using this for now as you've already said this gives you the best temps (comparable to Windows). If you can find out more about the missing C-states from your BIOS, then we can maybe revisit this in the future.. Or, in the mean time - maybe somebody else might spot something obvious here which I've missed? If though, one day you decide to save your ioreg again then please use the older v2.0 (2.0b1) of IORegistryExplorer that I've attached here and not the one I posted previously. IORegistryExplorer2.zip

10.04 - i386 1 - The creation method might be in question there, but ultimately if the end result is correct then it's still a valid file. 2 - So for a like for like replacement board, just different BIOS, your plan of attack should be to extract the ACPI tables (from Linux) and compare them with the ACPI tables you would have originally dumped from your old board (be it either using Linux or a different method back then). You may be surprised to find there's not much difference - meaning you can apply the same patches to your new DSDT or, amend your existing DSDT with the differences (if any) that you find in your new tables. That's great. So just to be clear here, all you're doing it dumping the ACPI tables from your BIOS without there being any influence from any boot loader used to boot OS X on your hack, and also grabbing any other details that aschar's script gathers . Once you have them, you can then begin comparing, stripping and patching them for your system to make them compatible for OS X.

Looking at your ACPI dump from Linux, I see you have an RSDT table where as I have an XSDT table. Have you ACPI 2.0 support disabled in your BIOS? if so, you will want to enable it. See pic:

Good for you Forgive me for not reading your thread thoroughly as I don't have lots of time right now. But it looks like you've spent some time patching a DSDT already and from what you say it worked. Well I guess your topic was titled "Is it the right way to create my own DSDT?" so Conti's reply was to that. He suggests using Linux to extract the ACPI tables from BIOS (which I also suggest you do - see PolishOX's thread here). Then you can always download an i386 v10.04 iso, burn the .iso to a CD-ROM and boot from it and follow the instructions in aschar's script (at the bottom of PolishOX's post). It's not actually that difficult. Otherwise there's DSDTSE as a secondary option.I loaded it up once and hated it. Maybe I didn't give it a chance and it really is a decent app but I have managed to work without it. But you have a DSDT that you made before don't you? If it works then can't you use that? Okay. But I wasn't suggesting you use it, just look at it for reference and comparison to yours. It may help - that's all

A common way these days is to use a dropbox account and post a link to the files.

Don't give up so easily Have you searched for anybody else using a DSDT for your board? Maybe like here? It might give you a starting point...

Okay. So this shows you have p-states with both options - and I get the exact same results with both options here (which makes sense as we are both using the same CPU, mono and boot loader in this case). So in theory you don't need to use the Chameleon boot options - but I see you still get the high temps when doing so. Did you manage to file->save the ioreg from IORegistryExplorer for each boot and not just a screengrab of the performancestatearrays ? This way I can check mine against yours.

I think the reason you don't get many answers is because ACPI is a huge subject and not many people have a wide, holistic, knowledge of it. Some names that spring to mind that I've seen demonstrate great skill in this area are THe KiNG and Masterchief for example, otherwise you will find a large number of users who know and understand certain parts of it and then many more, like me, who only know small parts which have been learned from reading and testing code posted by others. I have only scratched the surface throughout my endeavours to read the ACPIspec as it takes a lot of time and dedication to read and understand the code and then try to match it all against the chipset(s) of your own hardware. I would love to be able to say to you.. "Right then, this is what you need to do". But unfortunately, I can't. I fail at becoming an intellectual on ACPI because my brain always wants to do something else instead. The only real way to learn is to search and read from the myriad of topics that already exist in a number of forums, blogs and online resources, then roll up your sleeves and get stuck in with trial and error. Don't forget that our PC's BIOS knows nothing of OS X that we attempt to run on our hacks and for that a good starting place is to examine Apple's ACPI tables for reference to see how they do it. Pick yourself one issue which you have and concentrate on trying to fix that. Annotate the parts of the code as you learn about them, making changes slowly and checking the code still compiles as you go. And don't expect to get it right first time. With the right amount to time, patience, dedication and effort, it can be learned and the more time you spend on it, the more it will start to make sense. Sorry if this post doesn't give you an answer you were expecting but that's all I can give here. But I wish you every success in your quest

Run this to print Chameleon's boot log. bdmesg.zip As for a using a theme for Chameleon, see here.

Hi digital farmer. You can find a collection of Chameleon themes at the Theme Park section of the voodooprojects forum. Note: You'll need to be registered to see the downloads etc.

No, I don't think flashing your BIOS will prove anything and besides it always introduces an element of risk. No. I am very thankful for his kindness so I don't care about that. End of story. Could maybe a friend or someone else do it for you? Yes, I see you have a performance state array but with only two entries. Was this produced from your machine booted with or without using Chameleon's Generate PState/CState boot options? Also, I see the property numbers are all 0? (Looking here I see the same - it must be due to the v3.0 I sent you as v2.0 shows them indexed - maybe a bug?) EDIT: Okay - I've run a test here using the following Chameleon boot options: DropSSDT Yes GeneratePStates Yes GenerateCStates Yes Looking at Chameleon's boot log I see: Found ACPI CPU: P001 Found ACPI CPU: P002 Found ACPI CPU: P003 Found ACPI CPU: P004 Found ACPI CPU: P005 Found ACPI CPU: P006 Found ACPI CPU: P007 Found ACPI CPU: P008 SSDT with CPU C-States generated successfully P-States: min 0xc, max 0x14 SSDT with CPU P-States generated successfully RSDT: Added 2 SSDT table(s) Do you see similar? For further investigation, could you boot your machine without and with the above Chameleon boot options and then load up IORegistryExplorer and do a file->save and send me the file for comparison here?

No it's not that. I've just flashed my BIOS with v1701 and I still have all the options I showed previously with v1405. Booted in to OS X just fine and speedstep is working fine. No problem. It wasn't a warning - you just didn't need it. Well done And I can see your CPU Package Multiplier is at it's lowest p-state (x12) which is good. No. I've never had one and to be honest I didn't know what it was until I googled it to find out. Maybe one reads the temps for the CPU core and the other is reading the temp from the CPU casing? I don't know. You did say previously that "In Windows 7, temperatures get around 60-65ºC" - so at least we know OS X is reporting similar temps. Though I still can explain your high CPU temps other than question the cooling / mounting of the heatsink - which I know you've said is okay. Personally, I would look at removing it and re-mounting it just to be sure. You still shouldn't need to do that. But the thing is I'm not sure what your missing....I'm going to have to think some more. Here you go: IORegistryExplorer.zip You're welcome

Thanks for posting your org.chameleon.Boot.plist though it doesn't help reveal anything with regard to your power management - I was thinking maybe you had the DropSSDT boot option there but you don't. No matter, but I'm surprised you have so few options available considering we have the same motherboard (albeit different BIOS version) and CPU. I wonder why? BTW, you can remove the EthernetBuiltIn boot option as that's enabled in your DSDT. See here: Device (ETH0) { Name (_ADR, Zero) Method (_DSM, 4, NotSerialized) { Store (Package (0x02) { "location", Buffer (0x02) { "1" } }, Local0) DTGP (Arg2, RefOf (Local0)) Return (Local0) } } No. I said that option is now in IntelCPUMonitor.kext's info.plist - one of FakeSMC's plugins. But there's no need to change it as our CPU defaults to Tjmax of 100. I was just showing where the option was in case somebody else reading this wanted to know. You can use FakeSMC's plugins to help show your temps and working speedstep. Grab yourself the FakeSMC_plugins_Apps_rev609.zip from projectosx. Add IntelCPUMonitor.kext and WinbondW836x.kext to your /Extra folder alongside your existing FakeSMC.kext and re-run myHack -> myfix -> quick to update your myhack.kext and caches etc. then reboot. Once booted back up, run the HWMonitor app and you will see a new item in the menubar. You will then be able to see your temps and current multiplier. Here's a pic from my system: The multiplier changes here from 12 to 21 depending on what I'm doing. Well I didn't pay for it. I just entered my AppleID which is free to create when you use iTunes or the app store.

What boot options do you have in org.chameleon.Boot.plist? Maybe we need to double check your BIOS settings. This is what I see: Well done. The Tjmax setting is no longer in FakeSMC's info.plist but now in IntelCPUMonitor.kext's info.plist - one of FakeSMC's plugins. I think I'm right in saying it defaults to 100, but there is an existing entry to allow it to be changed. TjMax 0 However, a Tjmax of 100 is fine for the i7 920 2.67Ghz. Aida64 in Windows reports the following for my CPU: CPUID Manufacturer GenuineIntel CPUID CPU Name Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz CPUID Revision 000106A5h IA Brand ID 00h (Unknown) Platform ID 2Fh / MC 02h (LGA1366) Microcode Update Revision 11 HTT / CMP Units 2 / 4 Tjmax Temperature 100 °C (212 °F) CPU Thermal Design Power 130 W CPU Thermal Design Current 110 A Max Turbo Boost Multipliers  1C: 22x, 2C: 21x, 3C: 21x, 4C: 21x Yep - The developer tools are free. You can download the latest version from Apple's app store. Load up Xcode, then from the Xcode menu, select Open Developer Tool -> More Developer Tools… where you will be able to download the Hardware IO Tools for Xcode. We're going off topic here. But quickly, I'd say there's no need for any antivirus - just use your common sense if anything asks for your authentication. And yes, turn the firewall on.

Hi josh256 I've heard about this but I've never experienced it - i guess I'm lucky. The 10.7.4 kernel boots in to 64-bit mode fine here. No need to change anything. I do see the following SMC messages in my kernel log: SMC::smcInitHelper ERROR: MMIO regMap == NULL - fall back to old SMC mode SMC::smcReadKeyAction ERROR $Num kSMCKeyNotFound(0x84) fKeyHashTable=0x0 EDIT: I added key $Num to FakeSMC's info.plist so the error regarding that has now gone. All I can determine right now is that maybe AppleSMC is now looking for some extra stuff that FakeSMC doesn't provide. But having said that my iMac also has the following SMC errors in the kernel log: SMC::smcReadKeyAction ERROR: smcReadData8 failed for key DPLM (kSMCKeyNotReadable) SMC::smcReadKeyAction ERROR DPLM kSMCKeyNotReadable(0x85) fKeyHashTable=0x0xffffff8011f39000 SMC::smcReadKeyAction ERROR F0Sf kSMCBadArgumentError(0x89) fKeyHashTable=0x0xffffff8011f39000 SMC::smcReadKeyAction ERROR F1Sf kSMCBadArgumentError(0x89) fKeyHashTable=0x0xffffff8011f39000 SMC::smcReadKeyAction ERROR F2Sf kSMCBadArgumentError(0x89) fKeyHashTable=0x0xffffff8011f39000 SMC::smcInitHelper ERROR: MMIO regMap == NULL - fall back to old SMC mode SMC::smcWriteKeyAction ERROR CLWK kSMCBadArgumentError(0x89) fKeyHashTable=0x0xffffff8012f59000 After some reading on Apple's support forum I did read that maybe the logging of these SMC key requests to the kernel log is now active where as before they weren't? But I don't know. I hear Sandy Bridge CPU's have issues with speedstep but no problems with my 1st gen core i7. A quick geekbench shows a score of 9473 in 10.7.3 and 9434 in 10.7.4.