DSDT for Asus P8P67-M PRO

[Time2Retire]

I haven't tackled this part yet. But if those QSC values in fact set the GPU frequency I would be careful.

It's not. This is the power management (AppleGraphicsPowerManagement) aggressiveness (in milliseconds). When power management is turned off (aggressiveness = 0) then the GPU is never judged as idle. There are two functions called qscOn() and qscOff() to turn it on / off. Something I've learned while I was hacking the HP G72's AMD GFX0

 

I've added my support (on HF). Shall I invite tonymac Asus owner to contribute their support or are you good for now?

No "Mac" please, or we are screwed – Asus is (soon) a Apple manufacturer Sniff sniff I smell new MacPro's with new CPU's and chipsets

[flAked]

my dsdt.bin attached. much thanks.

Your ACPI tables are incomplete, how do you extract those? In OSX?

 

Which motherboard are you using?

 

BTW. Reading MSR's from different cores is easy. First you let it sleep, which triggers it to switch to a different core, and then you read it. It' all in CPUi.cpp Look at loopTimerEvent and specifically this part of it:

	// State Readout
IOSimpleLockLock(SimpleLock);
mp_rendezvous_no_intrs(IntelState, &magic);
IOSimpleLockUnlock(SimpleLock);

Well, this function, besides cpu_number() are exactly the two symbols which aren't found when compiling/loading CPUi for 64bit.

 

Those are legacy functions and not available any more. Any idea what could be the replacement?

[Time2Retire]

Well, this function, besides cpu_number() are exactly the two symbols which aren't found when compiling/loading CPUi for 64bit. Those are legacy functions and not available any more. Any idea what could be the replacement?

What if you add:

#define cpu_number()	get_cpu_number()
#define IOSimpleLockUnlock(l)	lck_spin_unlock(l)
#define IOSimpleLockLock(l)	lck_spin_lock(l)

See XNU's lapic.c and IOLocks.h

 

There's also IOSimpleLockLockDisableInterrupt and IOSimpleLockUnlockEnableInterrupt

[dhy8386]

Your ACPI tables are incomplete, how do you extract those? In OSX?

 

Which motherboard are you using?

 

Hopefully did as you said. I burned a copy of ubuntu 11.04 to disk. Started off the disk. Downloaded and installed acpidump. Opened a terminal window. Sudo bash to get me in as root user. Then ran the acpidump -o dsdt.bin which saved a copy that i uploaded. Did i screw something up?

 

I have the Asus mini itx P8H67-I Deluxe. Running the i5 2400.

[flAked]

What if you add:

#define cpu_number()	get_cpu_number()
#define IOSimpleLockUnlock(l)	lck_spin_unlock(l)
#define IOSimpleLockLock(l)	lck_spin_lock(l)

See XNU's lapic.c and IOLocks.h

Uh, sorry, wasn't very clear. The main problem is that "mp_rendezvous_no_intrs" or "mp_rendezvous" is no longer available. There was one discussion at the kernel dev list about it, saying why someone want's to do this

But actually, how would some one develop a SMP monitoring tool without it?

 

IOSimpleLock works as expected.

 

 

PS: you ninja'd me on HF, wrote something nice as well ;-)

[artimess]

I apologize if this is not right place to ask this question. I would appreciate if you could please give me a hand for the following. You guys conveinced me to get my hands dirty and start using RevoBoot. I have build the environment, congradulations to you it is really easy. However I have some questions. Here is the situation, I go through all the steps and bunch of files including a boot file is being created. My understanding is that this boot file replaces /boot file we get from Chameleon. Right? What about theother files where do they go?

 

Also, I changed setting.h to get some debugging info, where do they go because at boot time I do not see them? and bdmesg shows me my older boot messages?

 

What am I not doing right here?

 

Thanks for your help.

Artimess

[flAked]

Did i screw something up?

I have the Asus mini itx P8H67-I Deluxe. Running the i5 2400.

The additional SSDT's are missing, you could try "acpidump > acpi.dat" but that syntax could be from an old version. Then try "acpixtract -a acpi.dat" and see if you get any additional SSDTx.dat files.

 

I don't know if /proc/acpi/dsdt still exists in current Ubuntu, here is some more info http://smackerelofopinion.blogspot.com/200...pidump-and.html

 

But you will probably need an overhaul of the DSDT as well, giving you are the first H67 user around here?

 

 

What am I not doing right here?

The boot file is the only thing you need to copy. If you want DSDT/SSDT overwrites, your aml-files go into /Extra/ACPI and you need to set the options for replacing/dropping the tables as well. SMBIOS data is included as well.

 

To get you started, have a look at RevoBuilder https://github.com/blackosx/RevoBuilder

[ThisName]

No "Mac" please, or we are screwed – Asus is (soon) a Apple manufacturer Sniff sniff I smell new MacPro's with new CPU's and chipsets

 

Gotcha. Looks like you guys have got them under control anyhow Your second point would explain why HQ is locking our precious bit?

[Time2Retire]

Head is exploding. Going to call it a day...

[flAked]

Besides the tedious ASUS bugs and the unbelievable response at HF (I'm getting furious any minute now), is there anything we need to verify that SpeedStep is in fact working correctly?

 

Clock modulation would be a bonus addition of course.

 

How are the RevoBoot changes going, can I test something for you?

 

 

One thing I'm working on is getting the multiplier for every CPU, so we can assure that our SSDT_PR is working correctly and enables PM on all cores.

 

 

//RANT: BIOS options not actually disabling anything (proven by MSR readouts) is plain silly and I can't believe that the ASUS associate is answering by referring to Windows Power Management settings. I was calm and thoughtful thus far, but I'm just getting angry at this.

[THe KiNG]

@ flAked I saw you looked on ASUS EFI firmware for MSR stuff, what is the GUID of the culprit module?

To make your life easier, if you plan to hack the BIOS, attached is the AMI APTIO MMTool thanks to A. Woland from applelife.ru

 

I do plan to get a mini-itx board with an i3 2100t, as far I looked on forums seems all new UEFI boards has AICPUPM panics and all are made by AMI, Apple firmware is made by Insyde, so if we can find an Insyde based sandy bridge board or notebook we may get the answer on how to do it...

 

I had a quick look on this topic, from my experience all stuff you guys figured out are correct, except I do not agree on cleaning the SSDT until all stuff works OOTB, is best IMHO to keep/use Apple way to do things.

And I am not sure about _PSS/APSS what about CPU's that do not have Turbo(like i3 2100t)?

Also unknown register from Apple must be identified from someone who has sandy bridge apple machine and windows installed, AIDA64 can do great work there.

For example TCNT for me sounds like ThreadCouNT, and is verified in apple SSDT methods.

AMI_APTIO_MMTool.zip

[flAked]

@ flAked I saw you looked on ASUS EFI firmware for MSR stuff, what is the GUID of the culprit module?

To make your life easier, if you plan to hack the BIOS, attached is the AMI APTIO MMTool thanks to A. Woland from applelife.ru

Thank you very much, sir!

I don't know enough about the structure of EFI firmwares to find the correct spot. ASUS is locking MSR 0xE2, somewhere must be the wrmsr for it.

 

I do plan to get a mini-itx board with an i3 2100t, as far I looked on forums seems all new UEFI boards has AICPUPM panics and all are made by AMI, Apple firmware is made by Insyde, so if we can find an Insyde based sandy bridge board or notebook we may get the answer on how to do it...

AICPUPM is not panicing on Gigabyte boards, they have some sort of EFI bridge/emulation going on, but I don't know if they use AMI as well. At least it's a possibility that some of the faulty EFI code is based off faulty AMI code. Gigabyte is in fact using AWARD on P67.

 

I had a quick look on this topic, from my experience all stuff you guys figured out are correct, except I do not agree on cleaning the SSDT until all stuff works OOTB, is best IMHO to keep/use Apple way to do things.

Well, we did those edits having the ACPI tables from MBP8 and iMac12 at hand and basically do have all the important bits in there.

 

And I am not sure about _PSS/APSS what about CPU's that do not have Turbo(like i3 2100t)?

Also unknown register from Apple must be identified from someone who has sandy bridge apple machine and windows installed, AIDA64 can do great work there.

The APSS data needs to be custom made for every processor, so you would only have the normal P-States in there.

 

For example TCNT for me sounds like ThreadCouNT, and is verified in apple SSDT methods.

No. TCNT is used in _TSD (T-State Dependency) for the NumProcessor field. Trust me, we spent a lot of time reading ACPI and Intel specifications.

 

 

That reminds me. Why haven't we included TSD? (had it in an old revision)

[artimess]

The additional SSDT's are missing, you could try "acpidump > acpi.dat" but that syntax could be from an old version. Then try "acpixtract -a acpi.dat" and see if you get any additional SSDTx.dat files.

 

I don't know if /proc/acpi/dsdt still exists in current Ubuntu, here is some more info http://smackerelofopinion.blogspot.com/200...pidump-and.html

 

But you will probably need an overhaul of the DSDT as well, giving you are the first H67 user around here?

 

 

 

The boot file is the only thing you need to copy. If you want DSDT/SSDT overwrites, your aml-files go into /Extra/ACPI and you need to set the options for replacing/dropping the tables as well. SMBIOS data is included as well.

 

To get you started, have a look at RevoBuilder https://github.com/blackosx/RevoBuilder

 

Thanks for clarifying the fact that I only need the generated boot file. However my second part of the question which is where the debug and trace information go? I turned on some flags on the setting.h as it is said in the wikis to get some info like ACPI load address, etc, but I do not see them during the boot time? Is there any log file somewhere hidden that I can inspect to see the booting debug info?

 

Artimess

[flAked]

However my second part of the question which is where the debug and trace information go?

On your screen

Basically you can enable debugging for each sub-component.

 

Always use

make clean; make

[Time2Retire]

The first thing we should do is to let a GigaByte user, with the still to be assumed working P-States, what the output of MSRDumper.kext is.

 

If that looks ok, then we need a unmodified factory DSDT and a modified copy by TonyMac. This will tell us what they changed.

 

Anyone here able to do this pronto? Feel free to PM tony if you like, because seriously, the sooner we have this data, the sooner we can do something. Even if that is us ruling out their errors, which is still possible. No problem.

 

Now something else. I am testing a mini ssdt_pr.dsl to see what we need to get it register without errors. So far I have only APSS in CPU-1 through CPU-7 and no more T-State objects in CPU-0. Will keep you posted.

[artimess]

On your screen

Basically you can enable debugging for each sub-component.

 

Always use

make clean; make

 

Thanks again. I am having a compilation error, that occurs when I select to build the config files.

Here is the message

efi.c:51:51: error: empty character constant
make[2]: *** [efi.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

Compilation of RevoBoot for SNOW_LEOPARD Failed.

I looked at efi.c but could not figure out what is happening?

I think this coming from ../config/ACPI/EFI/data-template.h ?

 

What is the solution for this error? I am not touching any of these files and data.h seems correctly populated?

 

Thanks in advance,

Artimess

[flAked]

MSRDumper thread at tonymac

 

http://www.tonymacx86.com/viewtopic.php?f=79&t=20590

[Time2Retire]

We need at least a APSS object (method) and on all processor declarations, or we end up with the wrong value at:

 

IOPMrootDomain -> Power Status -> CPU_Power_Limits -> CPU_Available_CPUs [number]

 

Note: Apple has 8 so we need this on all processor declarations!

 

We also need ACST object (method) and the smallest possible one I could come up with is this one:

            Method (ACST, 0, NotSerialized)
           {
               Return (Package (0x03)
               {
                   One, // Unknown. Lowest C-State perhaps?
                   One, // Number of C-States.
                   Package (0x04)
                   {
                       ResourceTemplate ()
                       {
                           Register (FFixedHW, 
                               0x01,               // Bit Width
                               0x02,               // Bit Offset
                               0x0000000000000000, // Address
                               0x01,               // Access Size
                               )
                       }, 

                       One, 
                       0x03, // Worse case exit latency.
                       0x03E8 // Power in millivolts (1 Volt here).
                   }
               }
           }

Not keeping the number of C-States in sync will throw the following errors in kernel.log:

ACPI_SMC_PlatformPlugin::pushCPU_CSTData - cst_count (4) out of bounds
ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

During this run I used 4 instead of 3 hence the (4) here.

 

Please note that I am not saying that we don't need anything else, but merely that AICPUPM registers without errors.

[artimess]

Thanks again. I am having a compilation error, that occurs when I select to build the config files.

Here is the message

efi.c:51:51: error: empty character constant
make[2]: *** [efi.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

Compilation of RevoBoot for SNOW_LEOPARD Failed.

I looked at efi.c but could not figure out what is happening?

I think this coming from ../config/ACPI/EFI/data-template.h ?

 

What is the solution for this error? I am not touching any of these files and data.h seems correctly populated?

 

Thanks in advance,

Artimess

Can I get some help please?

[flAked]

Can I get some help please?

You need to copy the data-templates.h to data.h. If you look at config/data.h it tries to include the other data.h files based on your configuration options. That should do it.

 

And please don't quote whole posts, thanks.

 

We are quite busy at the moment, you'll have to do some digging yourself.

 

 

Ouch, either mp_rendezvous_no_intrs is not working as it should or we are in trouble:

May 25 19:08:28 slave kernel[0]: MSRDumper:	34 34 34  34 
May 25 19:08:28 slave kernel[0]: MSRDumper:	 34 34 34 34 
May 25 19:08:28 slave kernel[0]: MSRDumper:	34  34 3434  
May 25 19:08:28 slave kernel[0]: MSRDumper:	34  34 34 34 
May 25 19:08:28 slave kernel[0]: MSRDumper:	 16 16 16 16 
May 25 19:08:28 slave kernel[0]: MSRDumper:	11616  6  16 
May 25 19:08:28 slave kernel[0]: MSRDumper:	34  34 34 34 
May 25 19:08:28 slave kernel[0]: MSRDumper:	34 3434   34 
May 25 19:08:28 slave kernel[0]: MSRDumper:	16 16 16  16 
May 25 19:08:28 slave kernel[0]: MSRDumper:	16 16  16 16 
May 25 19:08:28 slave kernel[0]: MSRDumper:	26 26  26 26 
May 25 19:08:28 slave kernel[0]: MSRDumper:	 22 22 22 22 
May 25 19:08:28 slave kernel[0]: MSRDumper:   22   2222 2 2 
May 25 19:08:28 slave kernel[0]: MSRDumper:	 330 30 30 0

[Time2Retire]

We are quite busy at the moment, you'll have to do some digging yourself.

It's also the wrong spot to ask for help. Please read "How to boost the OS X boot process" from start to end - we've been over this a couple of times already.

 

 

Ouch, either mp_rendezvous_no_intrs is not working as it should or we are in trouble:....

Might be ok. I think to have read something about all cores going up/down in the Intel Speedstep thread.

 

Is this with EIST enabled and/or disabled? Dependencies or _PSD maybe?

 

Right. With EIST(C1E) enabled all cores go up/down at the same time. Was that why I disabled it maybe? And is this the next UEFI bug that is causing us trouble?

 

Here's an idea. What if we change MSRDumper.kext so that someone with a non-SB setup (and P-States working) can test your tool?

[flAked]

Right. With EIST(C1E) enabled all cores go up/down at the same time. Was that why I disabled it maybe? And is this the next UEFI bug that is causing us trouble?

The first run was with EIST disabled, Turbo on, C1E off.

The second run with EIST enabled, Turbo on, C1E on gives me the same behavior.

 

Maybe in my tests yesterday I hit another configuration bug, so something is stucked and I must somehow reset it?

 

BTW, my testings have shown that EIST is in fact never disabled via MISC_ENABLES bit, if Apple is reading this bit, EIST will always be on, regardless of the BIOS settings.

 

Here's an idea. What if we change MSRDumper.kext so that someone with a non-SB setup (and P-States working) can test your tool?

I can give it a spin on my MBP2,2 (I know, it's an old lady ). Oops, panic on ecx=0x35.

 

Interesting, both cores always swing at the same time. Something must have changed, because I hit 36x yesterday.

[Time2Retire]

BTW, my testings have shown that EIST is in fact never disabled via MISC_ENABLES bit, if Apple is reading this bit, EIST will always be on, regardless of the BIOS settings.

We already confirmed that 0x1A0 is read by AICPUPM (see list of used MSR's post #439).

Meaning we have to do wipe it our selfs. In the boot loader. At least for now. Until this bug get fixed in UEFI LOL if ever...

 

Something must have changed, because I hit 36x yesterday.

You don't see turbo speeds (multipliers) when EIST is disabled?

[flAked]

Meaning we have to do wipe it our selfs. In the boot loader. At least for now. Until this bug get fixed in UEFI LOL if ever...

I'm starting to get confused, why do we need to disable it again?

 

I'll take a break, be back in a couple of hours.

[Time2Retire]

I'm starting to get confused, why do we need to disable it again?

Because we want the AICPUPM to do this task? Not the BIOS?

 

I'll take a break, be back in a couple of hours.

Good idea.

 

Update: Say. Can't you check the temperatures instead of the multiplier. Or both?

 

Just read bits 16-22 of MSR 0x1A2 and 0x19C – the actually temperature is the value you get by reading 0x1a2 minus the value returned by 0x19c.