1905 replies to this topic

[iSoprano]

Master Chief, on Oct 19 2009, 05:39 PM, said:

I want you guys&gals to remove (comment out first if you like) the device_id bits of Method _DSM in all Device (UHCn) then tell me which board you have (ICH9 or ICH10) and if it works for you, or not of course.

Chief, for ICH9, system fails to sleep without the device_id bits.

[FKA]

William Parker, on Oct 20 2009, 10:30 AM, said:

Just an FYI. This took me in when I was sitting in front my computer with the air conditioner full blast. I had fixed dsdt & temps were around 33 C @idle. Next day I was back again @43-44. The weather was pleasant & so the AC was off, & I was ripping apart my dsdt to see what went wrong. Food was fuel for my brain, for while having lunch it struck me to switch the AC on & I was back @ 33.
So friends ambient temperatures do make a significant difference.
Hope this saves someone a wild goose chase.

Quite so ! it's just dropped down to around 13.C in London over the last week or so - if I don't have any heating on I'm just under 40.C - heating on it's back to 43 -44.C

[Master Chief]

iSoprano, on Oct 20 2009, 12:34 PM, said:

Chief, for ICH9, system fails to sleep without the device_id bits.

Too bad.  The main problem is that I don't have a GB board.  Hmm.  Someone said: "Get a PayPal account and I'll donate some dope to get you cracking".   Well.  I don't know.  Would that work?!?  I mean I don't like to ask for money, but having a GB would help me greatly of course.  And since I don't have a need for it... let me know what you guys think.

[pet1]

Will this dsdt.aml work with my board?  Isn't it suggested not to use dsdt.aml from other motherboards?

[Master Chief]

William Parker, on Oct 20 2009, 09:28 AM, said:

Sure thing. 2 files one called DSDT.dsl which is the current edit, working okay, and the koalal.dsl which was output from the patcher by fixing LAN, NVIDIA, HDEF, HPET, etc. only.
Thank you for looking.

I think I found something.  Let's have a look at a code block:

	OperationRegion (SMIC, SystemIO, 0xB2, One)
	Field (SMIC, ByteAcc, NoLock, Preserve)
	{
		SCP,	8
	}

	OperationRegion (APMP, SystemIO, 0xB2, 0x02)
	Field (APMP, ByteAcc, NoLock, Preserve)
	{
		APMC,   8, 
		APMD,   8
	}

				Scope (\)
				{
					OperationRegion (SCPP, SystemIO, 0xB2, One)
					Field (SCPP, ByteAcc, NoLock, Preserve)
					{
						SMIP,   8
					}
				}

All three basically the same.  And all three used to control Advanced Power Management.  The second one isn't even used in the DSDT so comment it out.  In fact do that for all three and add this:

Name(SCP, 0x80000000)
Name(SMIP, 0x80000000)

The idea is basically to eliminate the OperationRegion/Field combo's.  Let's see if you can do without them.  Food first now!

[mm67]

Master Chief, on Oct 20 2009, 07:03 PM, said:

I think I found something.  Let's have a look at a code block:

	OperationRegion (SMIC, SystemIO, 0xB2, One)
	Field (SMIC, ByteAcc, NoLock, Preserve)
	{
		SCP,	8
	}

	OperationRegion (APMP, SystemIO, 0xB2, 0x02)
	Field (APMP, ByteAcc, NoLock, Preserve)
	{
		APMC,   8, 
		APMD,   8
	}

				Scope (\)
				{
					OperationRegion (SCPP, SystemIO, 0xB2, One)
					Field (SCPP, ByteAcc, NoLock, Preserve)
					{
						SMIP,   8
					}
				}

All three basically the same.  And all three used to control Advanced Power Management.  The second one isn't even used in the DSDT so comment it out.  In fact do that for all three and add this:

Name(SCP, 0x80000000)
Name(SMIP, 0x80000000)

The idea is basically to eliminate the OperationRegion/Field combo's.  Let's see if you can do without them.  Food first now!

Works just fine with those modifications. Doesn't help with the usb clock-id's though.

[William Parker]

@ Master Chief

Thanks for that tip. I see someone beat me to it. Guessing it'll work for me as well. I won't be at my machine before tomorrow morning. Will do it first thing & post results.
Could you spare some more time & investigate why my Apple Keyboard does not wake the system, while my mouse does? Also auto sleep does not work.
As for the SBUS/EC parts I simply dittoed from user keeza's DSDT. I have no errors there apparently as it compiled fine. Could you confirm that it is okay as well as elaborate what benefit it is besides making it more maclike?

Thank you very much

[FKA]

William Parker, on Oct 20 2009, 06:01 PM, said:

@ Master Chief

Thanks for that tip. I see someone beat me to it. Guessing it'll work for me as well. I won't be at my machine before tomorrow morning. Will do it first thing & post results.
Could you spare some more time & investigate why my Apple Keyboard does not wake the system, while my mouse does? Also auto sleep does not work.
As for the SBUS/EC parts I simply dittoed from user keeza's DSDT. I have no errors there apparently as it compiled fine. Could you confirm that it is okay as well as elaborate what benefit it is besides making it more maclike?

Thank you very much

Out of interest is your keyboard in a USB hub or direct to one of the MB's ports?

D.

[Master Chief]

mm67, on Oct 20 2009, 06:32 PM, said:

Works just fine with those modifications. Doesn't help with the usb clock-id's though.

The purpose of this change is only to be able to remove the Windows/Linux bits from the DSDT simply because that for some is the main cause of PC Insomnia.

And now you should be able to remove Name (OSFX, One) and Name (OSFL, One)   And remember that OSFL is 0x02 so this:

			Method (_S3D, 0, NotSerialized)
			{
				If (LEqual (OSFL, 0x02))
				{
					Return (0x02)
				}
				Else
				{
					Return (0x03)
				}
			}

can be changed into this:

			Method (_S3D, 0, NotSerialized)
			{
				Return (0x02)
			}

You can also remove Method (^_INI, 0, NotSerialized) and Method (OSTP, 0, NotSerialized) and the calling code.   I hope that I didn't forget anything, and otherwise I'm here (or just PM me).  Whatever suits you best.

Note: You probably know this already, but I'll add it here for the rest of the clan who isn't that far.

William Parker, on Oct 20 2009, 07:01 PM, said:

@ Master Chief

Thanks for that tip. I see someone beat me to it. Guessing it'll work for me as well. I won't be at my machine before tomorrow morning. Will do it first thing & post results.
Could you spare some more time & investigate why my Apple Keyboard does not wake the system, while my mouse does? Also auto sleep does not work.
As for the SBUS/EC parts I simply dittoed from user keeza's DSDT. I have no errors there apparently as it compiled fine. Could you confirm that it is okay as well as elaborate what benefit it is besides making it more maclike?

Thank you very much

What we do is part of sleep and should also/eventually enable you to wake you hack with a single key press.

p.s. Mine is connected to the a port at the back of my hack, and connecting the mouse to the left/right port on the Apple keyboard also enables me to wake my hack by mouse.

[FKA]

Master Chief, on Oct 20 2009, 06:46 PM, said:

p.s. Mine is connected to the a port at the back of my hack, and connecting the mouse to the left/right port on the Apple keyboard also enables me to wake my hack by mouse.

This is also how my Apple Pro keyboard and Logitech mouse are connected - Both wake the machine from deep sleep.

[mm67]

Master Chief, on Oct 20 2009, 08:46 PM, said:

You can also remove Method (^_INI, 0, NotSerialized) and Method (OSTP, 0, NotSerialized) and the calling code.   I hope that I didn't forget anything, and otherwise I'm here (or just PM me).  Whatever suits you best.

Ok, removed everything except _INI methods. There is two in your dsdt, so which one should I remove. System still running fine. Here is my latest very heavily stripped down version.

 dsdt_stripped.dsl.zip   10.34K   68 downloads

[xopher]

I've added SBUS and EC to my DSDT, but without success. Can't get it to compile. Could someone check it out?

 DSDT_SBUS.EC.dsl.zip   17.99K   35 downloads

Thanks

[Master Chief]

mm67, on Oct 20 2009, 08:18 PM, said:

Ok, removed everything except _INI methods. There is two in your dsdt, so which one should I remove. System still running fine. Here is my latest very heavily stripped down version.

dsdt_stripped.dsl.zip

I was talking about this Method:

				Method (^_INI, 0, NotSerialized)
				{
					If (STRC (_OS, "Microsoft Windows"))
					{
						Store (0x56, SMIP)
					}
					Else
					{
						If (STRC (_OS, "Microsoft Windows NT"))
						{
							If (CondRefOf (\_OSI, Local0))
							{
								If (_OSI ("Windows 2001"))
								{
									Store (0x59, SMIP)
									Store (Zero, OSFL)
									Store (0x03, OSFX)
								}
							}
							Else
							{
								Store (0x58, SMIP)
								Store (Zero, OSFL)
							}
						}
						Else
						{
							Store (0x57, SMIP)
							Store (0x02, OSFL)
						}
					}
				}

Which I think you already removed.  Anyway.  Note the call to Method STRC since that can also be removed now, along with the two new Name([SCP/SMIP], 0x80000000) vars.  You should also be able to remove the following lines from Method _WAK:

		\_SB.DBEN ()
		Store (0xFF, DBG1)
		If (LEqual (Arg0, 0x03))
		{
			Store (0x8F, SCP)
		}

But the DBG1 bits must be checked first.  Also remove the following bits from Method _PTR:

		If (LEqual (Arg0, One)) {}
		If (LEqual (Arg0, 0x03)) {}
Store (0x99, SMIP)

The first two are meaningless, and the last line is just a leftover from your previous work.

[mm67]

Master Chief, on Oct 20 2009, 10:07 PM, said:

I was talking about this Method:

				Method (^_INI, 0, NotSerialized)
				{
					If (STRC (_OS, "Microsoft Windows"))
					{
						Store (0x56, SMIP)
					}
					Else
					{
						If (STRC (_OS, "Microsoft Windows NT"))
						{
							If (CondRefOf (\_OSI, Local0))
							{
								If (_OSI ("Windows 2001"))
								{
									Store (0x59, SMIP)
									Store (Zero, OSFL)
									Store (0x03, OSFX)
								}
							}
							Else
							{
								Store (0x58, SMIP)
								Store (Zero, OSFL)
							}
						}
						Else
						{
							Store (0x57, SMIP)
							Store (0x02, OSFL)
						}
					}
				}

Which I think you already removed.  Anyway.  Note the call to Method STRC since that can also be removed now, along with the two new Name([SCP/SMIP], 0x80000000) vars.  You should also be able to remove the following lines from Method _WAK:

		\_SB.DBEN ()
		Store (0xFF, DBG1)
		If (LEqual (Arg0, 0x03))
		{
			Store (0x8F, SCP)
		}

But the DBG1 bits must be checked first.  Also remove the following bits from Method _PTR:

		If (LEqual (Arg0, One)) {}
		If (LEqual (Arg0, 0x03)) {}
Store (0x99, SMIP)

The first two are meaningless, and the last line is just a leftover from your previous work.

Ok, all that is gone, still working great.

 stripped2.dsl.zip   10.08K   74 downloads

[Master Chief]

mm67, on Oct 20 2009, 09:49 PM, said:

Ok, all that is gone, still working great.

stripped2.dsl.zip

Great job.  Let's get cracking shall we?  Have a look at the following lines of code:

	Scope (\)
	{
		Name (PICF, Zero)
		Method (_PIC, 1, NotSerialized)
		{
			Store (Arg0, PICF)
		}
	}

And this is what the ACPI specification has to say about it:

"The \_PIC optional method is to report to the BIOS the current interrupt model used by the OS. This control method returns nothing. The argument passed into the method signifies the interrupt model OSPM has chosen, PIC mode, APIC mode, or SAPIC mode. Notice that calling this method is optional for OSPM. If the method is never called, the BIOS must assume PIC mode. It is important that the BIOS save the value passed in by OSPM for later use during wake operations."

Now note the last sentence, because that actually never happens in many of the DSDT's floating around here.  And your DSDT, like many, only has two options, being: PIC (BIOS default) or APIC.  What do you think about removing the extra bits?  Let's have a look at one of these snippets:

			Method (_PRT, 0, NotSerialized)
			{
				If (LNot (PICF))
				{
					Return (PICM)
				}
				Else
				{
					Return (APIC)
				}
			}

Our goal is to have one Return() only!   But that's not all of it because here's the longest part of it:

				Name (PICM, Package (0x10)
				{
					Package (0x04)
					{
						0xFFFF, 
						Zero, 
						LNKE, 
						Zero
					}, 

					Package (0x04)
					{
						0xFFFF, 
						One, 
						LNKD, 
						Zero
					}, 

					Package (0x04)
					{
						0xFFFF, 
						0x02, 
						LNKC, 
						Zero
					}, 

					Package (0x04)
					{
						0xFFFF, 
						0x03, 
						LNKA, 
						Zero
					}, 

					Package (0x04)
					{
						0x0001FFFF, 
						Zero, 
						LNKD, 
						Zero
					}, 

					Package (0x04)
					{
						0x0001FFFF, 
						One, 
						LNKC, 
						Zero
					}, 

					Package (0x04)
					{
						0x0001FFFF, 
						0x02, 
						LNKA, 
						Zero
					}, 

					Package (0x04)
					{
						0x0001FFFF, 
						0x03, 
						LNKE, 
						Zero
					}, 

					Package (0x04)
					{
						0x0002FFFF, 
						Zero, 
						LNKC, 
						Zero
					}, 

					Package (0x04)
					{
						0x0002FFFF, 
						One, 
						LNKA, 
						Zero
					}, 

					Package (0x04)
					{
						0x0002FFFF, 
						0x02, 
						LNKE, 
						Zero
					}, 

					Package (0x04)
					{
						0x0002FFFF, 
						0x03, 
						LNKD, 
						Zero
					}, 

					Package (0x04)
					{
						0x0007FFFF, 
						Zero, 
						LNK1, 
						Zero
					}, 

					Package (0x04)
					{
						0x0007FFFF, 
						One, 
						LNK1, 
						Zero
					}, 

					Package (0x04)
					{
						0x0007FFFF, 
						0x02, 
						LNK1, 
						Zero
					}, 

					Package (0x04)
					{
						0x0007FFFF, 
						0x03, 
						LNK1, 
						Zero
					}
				})
				Name (APIC, Package (0x10)
				{
					Package (0x04)
					{
						0xFFFF, 
						Zero, 
						Zero, 
						0x14
					}, 

					Package (0x04)
					{
						0xFFFF, 
						One, 
						Zero, 
						0x13
					}, 

					Package (0x04)
					{
						0xFFFF, 
						0x02, 
						Zero, 
						0x12
					}, 

					Package (0x04)
					{
						0xFFFF, 
						0x03, 
						Zero, 
						0x10
					}, 

					Package (0x04)
					{
						0x0001FFFF, 
						Zero, 
						Zero, 
						0x13
					}, 

					Package (0x04)
					{
						0x0001FFFF, 
						One, 
						Zero, 
						0x12
					}, 

					Package (0x04)
					{
						0x0001FFFF, 
						0x02, 
						Zero, 
						0x10
					}, 

					Package (0x04)
					{
						0x0001FFFF, 
						0x03, 
						Zero, 
						0x14
					}, 

					Package (0x04)
					{
						0x0002FFFF, 
						Zero, 
						Zero, 
						0x12
					}, 

					Package (0x04)
					{
						0x0002FFFF, 
						One, 
						Zero, 
						0x10
					}, 

					Package (0x04)
					{
						0x0002FFFF, 
						0x02, 
						Zero, 
						0x14
					}, 

					Package (0x04)
					{
						0x0002FFFF, 
						0x03, 
						Zero, 
						0x13
					}, 

					Package (0x04)
					{
						0x0007FFFF, 
						Zero, 
						Zero, 
						0x17
					}, 

					Package (0x04)
					{
						0x0007FFFF, 
						One, 
						Zero, 
						0x17
					}, 

					Package (0x04)
					{
						0x0007FFFF, 
						0x02, 
						Zero, 
						0x17
					}, 

					Package (0x04)
					{
						0x0007FFFF, 
						0x03, 
						Zero, 
						0x17
					}
				})

Ok.  This is a rather long example, but there are others which are less long, but clutter the DSDT.  What do you think?  Are you able to remove the extra bits?

But this time I won't tell you what to remove or how to change it.  Let's call it a challenge.  Here's one tip I have for you: Add an If clause to this code:

Load (IST0, HI0)

to check the value of PICF.  This is basically everything you'll need to know.  More even so surprise me

Good luck!

xopher, on Oct 20 2009, 08:22 PM, said:

I've added SBUS and EC to my DSDT, but without success. Can't get it to compile. Could someone check it out?

DSDT_SBUS.EC.dsl.zip

Thanks

You sir should be able to use the great work done by fellow GB user/owner mm67 or at least verify/compare your changes with his DSDT, or try diff -uw old-file.dsl new-file.dsl

[xopher]

Master Chief, on Oct 21 2009, 12:19 AM, said:

You sir should be able to use the great work done by fellow GB user/owner mm67 or at least verify/compare your changes with his DSDT, or try diff -uw old-file.dsl new-file.dsl

That I realized a moment ago. I tried mm67's DSDT, and it works on my board as well. Checked the tech-specs and the only (obvious) differences between the boards are the absence of eSata and RAID on mm67's m/b.

I had to add some bits (device-id) to get LPC to load, I then added my PSS-tables, but otherwise it booted superbly. How can I verify that SBUS/EC are working?

I have the same problem with sleep as I did with my DSDT though, sleeps fine, but on wake-up (by mouse works, but..) it restarts.

Thank you MasterChief and kiitos mm67, for putting up with me ;-) I've already learned a lot.

[Master Chief]

xopher, on Oct 20 2009, 11:27 PM, said:

That I realized a moment ago. I tried mm67's DSDT, and it works on my board as well. Checked the tech-specs and the only (obvious) differences between the boards are the absence of eSata and RAID on mm67's m/b.

I had to add some bits (device-id) to get LPC to load, I then added my PSS-tables, but otherwise it booted superbly. How can I verify that SBUS/EC are working?

I have the same problem with sleep as I did with my DSDT though, sleeps fine, but on wake-up (by mouse works, but..) it restarts.

Thank you MasterChief and kiitos mm67, for putting up with me ;-) I've already learned a lot.

That's what we're here for.  Having a bit of fun, and to learn something new.

Here's a little howto for Device (SBUS): kextstat|grep SMBus
   30    2 0x555c1000 0x3000     0x2000     com.apple.iokit.IOSMBusFamily (1.1) <5 4 3>
   67    0 0x5ca8a000 0x2000     0x1000     com.apple.driver.AppleSMBusPCI (1.0.2d0) <14 5 4 3>
   79    0 0x5c2b8000 0x9000     0x8000     com.apple.driver.AppleSMBusController (1.0.2d0) <30 14 13 5 4 3>

Then do a kextstat|grep AppleIntel in a terminal window, this to check whether one or multiple CPU type kexts are loaded – you should only see one!  Here's an example:

   89    0 0x5c6e5000 0x7000     0x6000     com.apple.driver.AppleIntelPenrynProfile (17) <71 6 4 3>

[xopher]

Master Chief, on Oct 21 2009, 02:10 AM, said:

That's what we're here for.  Having a bit of fun, and to learn something new.

Here's a little howto for Device (SBUS): kextstat|grep SMBus
   30    2 0x555c1000 0x3000     0x2000     com.apple.iokit.IOSMBusFamily (1.1) <5 4 3>
   67    0 0x5ca8a000 0x2000     0x1000     com.apple.driver.AppleSMBusPCI (1.0.2d0) <14 5 4 3>
   79    0 0x5c2b8000 0x9000     0x8000     com.apple.driver.AppleSMBusController (1.0.2d0) <30 14 13 5 4 3>

Then do a kextstat|grep AppleIntel in a terminal window, this to check whether one or multiple CPU type kexts are loaded – you should only see one!  Here's an example:

   89    0 0x5c6e5000 0x7000     0x6000     com.apple.driver.AppleIntelPenrynProfile (17) <71 6 4 3>

Ok, I do see the SMBus-devices, but kextstat -k | grep AppleIntel gives me all these three:
com.apple.driver.AppleIntelCPUPowerManagement (90.0.0) <7 6 5 4 3 1>
com.apple.driver.AppleIntelCPUPowerManagementClient (90.0.0) <7 6 5 4 3 1>
com.apple.driver.AppleIntelPenrynProfile (17) <69 6 4 3>

Does this mean that the kexts (LegacyACPI_SMC_PP.kext and LegacyAGPM.kext) are not loading properly?

[Master Chief]

xopher, on Oct 21 2009, 01:57 AM, said:

Ok, I do see the SMBus-devices, but kextstat -k | grep AppleIntel gives me all these three:
com.apple.driver.AppleIntelCPUPowerManagement (90.0.0) <7 6 5 4 3 1>
com.apple.driver.AppleIntelCPUPowerManagementClient (90.0.0) <7 6 5 4 3 1>
com.apple.driver.AppleIntelPenrynProfile (17) <69 6 4 3>

Does this mean that the kexts (LegacyACPI_SMC_PP.kext and LegacyAGPM.kext) are not loading properly?

There's only one AppleIntel*Profile and thus it's ok.

[xopher]

Master Chief, on Oct 21 2009, 03:05 AM, said:

There's only one AppleIntel*Profile and thus it's ok.

Great! Actually, if I run kextstat right after boot, it shows Merom and Nehalem as well, but they're unloaded after a while it seems. Update: Confirmed, I rebooted and got the same result.