833 replies to this topic

[davidm71]

Sorry to hear about her grandmother. Anyhow here are the acpi dumps for my Asus P8P67 Deluxe rev3 2600K board...

Thanks.

Attached Files

•  dumps.tar.gz   101.53K   5 downloads

[mrmojorisin17]

DutchHockeyPro, on Apr 29 2011, 08:33 PM, said:

One of my grandmothers died today so I am prolly off-line for some time. Need to get my thought straiten out first. Just so sad for grandpa  

So sorry
Very difficult to say something about that...
Wish you all the best and take care of grandpa

[flAked]

davidm71, on Apr 29 2011, 08:25 PM, said:

Sorry to hear about her grandmother. Anyhow here are the acpi dumps for my Asus P8P67 Deluxe rev3 2600K board...

Thanks.

Could you post the exact differences between the Normal and Deluxe version? Thanks.

Edit: I mean different numbers of PCI-lanes, more USB ports, etc.

[mrmojorisin17]

Hi all
A fantastic tool for Windows that allows to extract all ACPI Tables: RW - Read & Write.
An helpful alternative for people like me having trouble to get this info from Linux.
Hope this help

[flAked]

Some new findings as I switch to RevoBoot

1) Device definitions may cause troubles:

Device (GFX0)
{
	Name (_ADR, Zero)
}

Disables Q/E for my GTS250.

Device (BR24)	// PCI-bridge
{
	Name (_ADR, Zero)
	Alias (AR17, _PRT)
	Alias (PWB4, _PRW)
}

The same goes for the PCI-bridge definition. My sound-card driver cmi8738 won't load correctly.
However, GIGE, SATA and some others work fine. I don't know why that is, might be a IOMatching problem.


2) We need to drop SSDT's, otherwise P001-3 will get matched as additional CPU's (with own ID's) to our CPU0-3. Replacing existing ones doesn't work correctly in the case of SSDT_PR.


3) More of a question, if I boot Chameleon and use efidp2struct, which data is actually extracted? I tried adding the data to a CFDictionary but couldn't dump the information.

[davidm71]

Hi,

I tried to do the basic Nvidia display dsdt patch within the DSDTse Editior and had issues. I used ioregistry explorer to find my addresses which where something like 0x00010000,0x00010001,0x001C0000 as my gpu root pci ids are (x0,x0),(x1,x0),(x0,x0) and (x0,x0),(x1,x1),(x0,x0), and (x0,x0),(x1C,x0),(x0,x0). Plugging those values into a hex device id gfx string in the com.apple.boot.plist file worked and gave me multigpu support but putting those into a DSDT file that I used DSDTse to pull ended up causing a reboot and black screen. Thats even after removing the DSDT.aml files from the root and Extra folder!

I know I'm a beginner at this but I don't have the slightest idea why I can't revert back to how it was even after putting back my original gfx string into the boot.plist file? I tried running pfix to rebuild the cache and still that partition is borked!


Anyone care to comment please?

Thank you.

Note: I made appropriate edits to the NVCAP section as well and even took it one gpu at a time...

[davidm71]

mrmojorisin17, on May 1 2011, 04:22 PM, said:

Take a look at this

Thank you but how do I install that piece of code? Its a SSDT file correct? I guess I will have to study about SSDTs more.. Will I have to modify the NVCAP section based on ioregistry info? Also will Ioregistryexplorer be influenced by my current device-id string? Such that if I have already a generic nvidia device-id gfx string will copying ioexplorer display info be accurate to my particular hardware?

Thanks

[flAked]

I know it's tempting, but please try and keep on topic.

Now, onto new findings.


The reason why SMC_PlatformPlugin is acting so quiet is because there is no PM-definition for MacBookPro8,1 in the IOPlatformPluginFamily if we are using stock 10.6.7 with just the new kernel. It is also not part of the MBP2011 10.6.7 update, bummer.

By setting MacPro5,1 SMC_PlatformPlugin loads further and is now complaining about:

    ACPI_SMC_PlatformPlugin::gatherCStateOverrides - failed to set c-state demotion data: -1


At the moment I'm experimenting with more SSDT_PR implementations and did PDC, TSS and TPC without success.
I hope we get more fun out of the new iMac's and a 10.6.8 on the horizon next week!

[mrmojorisin17]

Can you gently attach here your new(s) SSDT_PR or a diff to see what you added?
Thanks

[flAked]

mrmojorisin17, on May 1 2011, 05:22 PM, said:

Can you gently attach here your new(s) SSDT_PR or a diff to see what you added?
Thanks

My assumptions were wrong in the last post. The PM-definition for MacPro5,1 has a CStateDemotion-property, which seems to be specific to the CPU so it fails on mine. This brings us no further.
I crafted my own definition for the MacBookPro8,3, but it doesn't change anything.

We need to figure out why IntelCPUPM is crashing and _then_ configure our CPU correctly via SMC_PlatformPlugin.

My SSDT_PR is a mess right now and potentially dangerous. It also doesn't change anything. I don't know if the MBP8,3 actually has T-States and if OSX is using them.

If you are curious I added Methods _TPC, _PTC and _TSS - you can check them out in the ACPI specification.

- TPC defines which T-States are available
- PTC is doing the actual throttling and
- TSS defines the T-States

IntelCPUPM is crashing with a correct implementation of those methods, so they are irrelevant at this point.

EDIT: Err, I totally forgot that we were suspecting TSS to generate the missing P-states.

In my vanilla SSDT, TSS is defined like that:

Name (TSS, Package (0x01) //Throttle off, 100%
		{
			Package (0x05)
			{
				0x64, 
				0x03E8, 
				Zero, 
				Zero, 
				Zero
			}
		})

The 0x64 = 100% and there are 2 more T-states with a lesser percentage. This corresponds the the ACPI specs.
But I think Apple is using this differently. The invocation of _TSS generates some data and writes it to either TSMF or TSMC, using PSS as a reference.

Sam, could you send me the dumps for the MBP8,3 please?

[mrmojorisin17]

polyglot, on May 1 2011, 11:45 PM, said:

...

Thanks for the info man

Quote

Sam, could you send me the dumps for the MBP8,3 please?

Hope this help...
MBP8,1

•  MacBookPro8_1_ACPI.zip   76.24K   11 downloads
  
•  MacBookPro8_1_ioreg_IOPower_only.zip   16.75K   9 downloads
  
•  MacBookPro8_1_lspci.zip   1.83K   7 downloads

MBP8,2

•  MacBookPro8_2_ACPI.zip   76.12K   16 downloads
  
•  MacBookPro8_2_lspci.zip   6.69K   12 downloads

MBP8,3

•  MacBookPro8_3_ioreg_not_full.zip   56.56K   17 downloads
  
•  MacBookPro8_3_SP.zip   222.52K   19 downloads

[flAked]

mrmojorisin17, on May 2 2011, 08:52 AM, said:

Hope this help...

Delicious ACPI-tables! Thanks.

I'll have a look at them later.

[Time2Retire]

Oops. I thought that the AGPM stuff was common knowledge since my father introduced people to it, so I didn't bother to mention it here. Sorry. And one thing I would like to add is that the MBP8,1 should be left alone because that one won't work. The MBP8,2 and bigger brother 8,3 are a better match (for now).

BTW: I already use the iMac12_1.plist but it sure isn't a perfect match. Need modifications since not everyone will have a... wait I can't tell you that yet...

/me ducks

Correction:
Do not remove the following code. This is something Apple uses. It was pretty much hidden, but adding the boot flag debug=127 revealed the error; ACPI: setPicMode AE_NOT_FOUND

One other thing. dgsga removed the _PIC method from his DSDT and at first I thought that he had done something stupid, but he is right. I cross checked two stripped DSDT's of a P5K PRO and he is right. Dad removed it in 2009 so no. We don't need it – Apple is using the ACPI APIC mode (not legacy PIC) so we can safely remove the following three  code snippets from our DSDT:

Method (_PIC, 1, NotSerialized)
	{
		Store (0xAA, DBG8)
	}

and:

OperationRegion (DEB0, SystemIO, 0x80, One)
	Field (DEB0, ByteAcc, NoLock, Preserve)
	{
		DBG8,   8
	}

and:

Device (IPIC)	// Renamed from: PIC
				{
					Name (_HID, EisaId ("PNP0000"))
					Name (_CRS, ResourceTemplate () {
						IO (Decode16,
							0x0020,			 // Range Minimum
							0x0020,			 // Range Maximum
							0x00,			   // Alignment
							0x02,			   // Length
							)
						IO (Decode16,
							0x00A0,			 // Range Minimum
							0x00A0,			 // Range Maximum
							0x00,			   // Alignment
							0x02,			   // Length
							)
						IRQNoFlags ()
							{2}
					})
				}

And that brings us to the exact spot why Lion can't boot without the dreadful double fault. Yup. These are the registers cparm writes to in boot.c with his patch for Chameleon.

Now read this in the ACPI specification:

Quote

A one indicates that the system also has a PC-AT-compatible dual-8259 setup. The 8259 vectors must be disabled (that is, masked) when enabling the ACPI APIC operation.

Oh yes. That's your MADT flags (PCAT_COMPAT) in APIC.dsl And while some say that something has changed, which is true because Apple went from ACPI v1.5 to ACPI 3.0a, but this is just a silly bug.

[flAked]

DutchHockeyPro, on May 2 2011, 12:50 PM, said:

BTW: I already use the iMac12_1.plist but it sure isn't a perfect match. Need modifications since not everyone will have a... wait I can't tell you that yet...

You are such a teaser  

DutchHockeyPro, on May 2 2011, 12:50 PM, said:

Apple is using the ACPI APIC mode (not legacy PIC) so we can safely remove the following three  code snippets from our DSDT.

Working great without them, thanks for the info.

With the MBP8 dumps I replicated the whole SSDT_PR and figured out what the _TSS method does and where the missing P-States are coming from. It's rather simple.

1) _PSS as we know it, defines normal P-states + a meta Turbo state. But there is another table named APSS, that defines all states, including Turbo modes. I now have all of them correctly showing up in IOReg.

Name (PSS, Package (0x10)
		{
	/*  Core Frequency (MHz), Power (milliwats), Latency (ms), Bus Latency (ms), Control, Status */
			Package (0x06) { /* 3301 MHz */ 0xCE5, 0x17318, 10, 10, /* 37 */ 0x2500, 0x2500 },
			Package (0x06) { /* 3300 MHz */ 0xCE4, 0x17318, 10, 10, /* 33 */ 0x2100, 0x2100 }, 
			Package (0x06) { /* 3200 MHz */ 0xC80, 0x163c6, 10, 10, /* 32 */ 0x2000, 0x2000 }, 
			Package (0x06) { /* 3100 MHz */ 0xC1C, 0x154ba, 10, 10, /* 31 */ 0x1F00, 0x1F00 }, 
			Package (0x06) { /* 3000 MHz */ 0xBB8, 0x145f5, 10, 10, /* 30 */ 0x1E00, 0x1E00 }, 
			Package (0x06) { /* 2900 MHz */ 0xB54, 0x13776, 10, 10, /* 29 */ 0x1D00, 0x1D00 }, 
			Package (0x06) { /* 2800 MHz */ 0xAF0, 0x1293c, 10, 10, /* 28 */ 0x1C00, 0x1C00 }, 
			Package (0x06) { /* 2700 MHz */ 0xA8C, 0x11b47, 10, 10, /* 27 */ 0x1B00, 0x1B00 }, 
			Package (0x06) { /* 2600 MHz */ 0xA28, 0x10d96, 10, 10, /* 26 */ 0x1A00, 0x1A00 }, 
			Package (0x06) { /* 2500 MHz */ 0x9C4, 0x10028, 10, 10, /* 25 */ 0x1900, 0x1900 }, 
			Package (0x06) { /* 2400 MHz */ 0x960, 0xf2fe, 10, 10, /* 24 */ 0x1800, 0x1800 }, 
			Package (0x06) { /* 2300 MHz */ 0x8FC, 0xe616, 10, 10, /* 23 */ 0x1700, 0x1700 },
			Package (0x06) { /* 2200 MHz */ 0x898, 0xd971, 10, 10, /* 22 */ 0x1600, 0x1600 }, 
			Package (0x06) { /* 2100 MHz */ 0x834, 0xcd0c, 10, 10, /* 21 */ 0x1500, 0x1500 }, 
			Package (0x06) { /* 2000 MHz */ 0x7D0, 0xc0e9, 10, 10, /* 20 */ 0x1400, 0x1400 }, 
			Package (0x06) { /* 1600 MHz */ 0x640, 0x92d9, 10, 10, /* 16 */ 0x1000, 0x1000 }
		})
Name (APSS, Package (0x13)
		{
	/*  Core Frequency (MHz), Power (milliwats), Latency (ms), Bus Latency (ms), Control, Status */
			Package (0x06) { /* 3700 MHz */ 0xE74, 0x17318, 10, 10, /* 37 */ 0x2500, 0x2500 },
		Package (0x06) { /* 3600 MHz */ 0xE10, 0x17318, 10, 10, /* 36 */ 0x2400, 0x2400 }, 
		Package (0x06) { /* 3500 MHz */ 0xDAC, 0x17318, 10, 10, /* 35 */ 0x2300, 0x2300 }, 
		Package (0x06) { /* 3400 MHz */ 0xD48, 0x17318, 10, 10, /* 34 */ 0x2200, 0x2200 }, 
			Package (0x06) { /* 3300 MHz */ 0xCE4, 0x17318, 10, 10, /* 33 */ 0x2100, 0x2100 }, 
			Package (0x06) { /* 3200 MHz */ 0xC80, 0x163c6, 10, 10, /* 32 */ 0x2000, 0x2000 }, 
			Package (0x06) { /* 3100 MHz */ 0xC1C, 0x154ba, 10, 10, /* 31 */ 0x1F00, 0x1F00 }, 
			Package (0x06) { /* 3000 MHz */ 0xBB8, 0x145f5, 10, 10, /* 30 */ 0x1E00, 0x1E00 }, 
			Package (0x06) { /* 2900 MHz */ 0xB54, 0x13776, 10, 10, /* 29 */ 0x1D00, 0x1D00 }, 
			Package (0x06) { /* 2800 MHz */ 0xAF0, 0x1293c, 10, 10, /* 28 */ 0x1C00, 0x1C00 }, 
			Package (0x06) { /* 2700 MHz */ 0xA8C, 0x11b47, 10, 10, /* 27 */ 0x1B00, 0x1B00 }, 
			Package (0x06) { /* 2600 MHz */ 0xA28, 0x10d96, 10, 10, /* 26 */ 0x1A00, 0x1A00 }, 
			Package (0x06) { /* 2500 MHz */ 0x9C4, 0x10028, 10, 10, /* 25 */ 0x1900, 0x1900 }, 
			Package (0x06) { /* 2400 MHz */ 0x960, 0xf2fe, 10, 10, /* 24 */ 0x1800, 0x1800 }, 
			Package (0x06) { /* 2300 MHz */ 0x8FC, 0xe616, 10, 10, /* 23 */ 0x1700, 0x1700 },
			Package (0x06) { /* 2200 MHz */ 0x898, 0xd971, 10, 10, /* 22 */ 0x1600, 0x1600 }, 
			Package (0x06) { /* 2100 MHz */ 0x834, 0xcd0c, 10, 10, /* 21 */ 0x1500, 0x1500 }, 
			Package (0x06) { /* 2000 MHz */ 0x7D0, 0xc0e9, 10, 10, /* 20 */ 0x1400, 0x1400 }, 
			Package (0x06) { /* 1600 MHz */ 0x640, 0x92d9, 10, 10, /* 16 */ 0x1000, 0x1000 }
		})

2) the mysterious _TSS method is looking up index 0x1 in the PSS table (Power in mW) to populate the power field in the TSS table for processor throttling. ACPI specs are saying this value is normally ignored if P-states are defined, oh well. They are doing it anyways.

But as I'm ignoring additional throttling, I'm only defining one T-state (100%) and hardcoded the max TDP to 95W.

I now have this near replicate to the original SSDT and it still crashes. I'm wondering if the TableID in the DefinitionBlock at the beginning of the SSDT's are important.


 ssdt_pr.dsl.zip   3.37K   22 downloads

For the curious here is my complete rewrite of SSDT_PR, in this version I copied the SSDT-definition at the top to test if I could read out the C-states in their manner (thats why CMST is commented out). This might be rather dangerous.
Additionally there are some interesting comments throughout the file.


Edit: uhh, found a little bug. PSS must be called _PSS. Not that it makes a difference right now...

[mrmojorisin17]

I can safely test your SSDT_PR whit my system?

[flAked]

mrmojorisin17, on May 2 2011, 06:26 PM, said:

I can safely test your SSDT_PR whit my system?

I'm currently running it on my system and didn't have any crashes. But after a test I would revert to your current version.
Try and see if IntelCPUPM loads.

In your DSDT.aml you need to change "Scope (_PR)" into "Scope (\_PR)" - not sure it's necessary, but I changed the SSDT to fit the original and they did it this way.

[Time2Retire]

What about this:

Quote

I now have this near replicate to the original SSDT and it still crashes. I'm wondering if the TableID in the DefinitionBlock at the beginning of the SSDT's are important.

So he will get a KP or not?

BTW. I no longer have a _PSS object but only APSS in CPU0 and that works. That is. I see my 22 P-States in IORegistryExplorer. All other references to _PSS have been removed. Don't seem to need them anymore (because that was old school?). And yes. It still KP's like ever before.

p.s. APSS is read / used by ACPI_SMC_PlatformPlugin

[mrmojorisin17]

Currently testing your new SSDT_PR...

HackPro-di-mrmojorisin17:~ mrmojorisin17$ kextstat
   Index Refs Address			Size	   Wired	  Name (Version) <Linked Against>
   com.apple.driver.AppleIntelCPUPowerManagement (142.4.1) <7 6 5 4 3 1>

All appears to be ok.
One question: why in IORegistry I have CPU0,1,2,3 and also P000,1,2,3?
Thanks

p.s. In E/E I have NullCPUPowerManagement.kext yet.
If I remove it I'll get a kp with dependencies AppleIntelCPUPowerManagement.kext.

[Time2Retire]

mrmojorisin17, on May 2 2011, 09:16 PM, said:

Currently testing your new SSDT_PR...
All appears to be ok. One question: why in IORegistry I have CPU0,1,2,3 and also P000,1,2,3?
Thanks

You need to drop the factory SSDT's. That's been said before here

I also have that in my kextstat output:

com.apple.driver.AppleIntelCPUPowerManagement (142.4.1) <7 6 5 4 3 1>

but I still need NullCPUPowerManagement (:

[flAked]

DutchHockeyPro, on May 2 2011, 07:13 PM, said:

What about this:

So he will get a KP or not?

BTW. I no longer have a _PSS object but only APSS in CPU0 and that works. That is. I see my 22 P-States in IORegistryExplorer. All other references to _PSS have been removed. Don't seem to need them anymore. And yes. It still KP's line ever before.

It will panic, sorry if I was misleading. I posted my edits to document the process.

Now thats interesting, seems they only read APSS and kept _PSS for some reason. At this point I'd like to be on the safe side and leave it in for now. That way we can rule it out in case of more errors later on.
I'll add a note that it could be removed once we load AICPUPM successfully.