Jump to content

blackosx

Retired
  • Content Count

    33
  • Joined

  • Last visited

Community Reputation

0 Neutral

About blackosx

  • Rank
    Major General

Profile Information

  • Location
    UK
  1. 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 i
  2. 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 (
  3. 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:
  4. 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 botto
  5. A common way these days is to use a dropbox account and post a link to the files.
  6. 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...
  7. 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.
  8. 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 d
  9. Run this to print Chameleon's boot log. bdmesg.zip As for a using a theme for Chameleon, see here.
  10. 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.
  11. 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 - mayb
  12. 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 tha
  13. 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)
  14. 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
  15. 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. B
×
×
  • Create New...