Jump to content

HP Pavilion HPE-180t DSDT Help


VerizonLover
 Share

16 posts in this topic

Recommended Posts

EDIT: Fixed the DSDT error by changing

 

 

Acquire(MUTE, 0x3e8)

to

 

 

Acquire(MUTE, 0xffff)

 

However, in the SSDT, I'm still getting the following error:

 

Object not found or not accessible from scope (_PR_.P001)

Forward references from Scope operator not allowed (_PR_.P001)

 

And the offending line is:

 

Scope (\_PR_.P001)

 

Those kind of errors continue up to "_PR_.P016". How do I fix that error?

Link to comment
Share on other sites

Attached is a new DSDT with the following patches applied, in listed order (from DSDT Patcher for Wndows/Linux, latest revision):

 

DTG

 

IRQs

 

LAN0

 

LPC ICH10

 

LPC NEHALEM

 

Mac devices

 

Possible operator timeout is ignored

 

New HPET

 

HDEF

 

SBUS

 

 

 

Are those the right patches, or what changes should I make?

Link to comment
Share on other sites

for what chipset . laptop or desktop ? (details)

 

System: HP Pavilion HPE-180t

Chipset: X58

Motherboard: Pegatron IPMTB-TK

RAM: Micron 1066Mhz DDR3 (6x2GB)

Hard Drive: Seagate 1.5TB ST31500341AS

DVD-ROM Drive: HP DH16D5S

DVD+RW Drive: HP DH16AAL

Keyboard: Logitech MX3200

Mouse: Logitech MX610

Network: Intel 82567V-2

Video: MSI N220GT 1GB

Audio: Integrated Realtek 888S

Video Capture: Hauppauge WinTV HVR-1290

Webcam: Logitech Quickcam Pro 9000

UPS: APC Back-UPS Pro RS 1500

Link to comment
Share on other sites

Attached is a new DSDT with the following patches applied

Your post doesn't have any attachments.

Are those the right patches, or what changes should I make?

That depends on what problem you're trying to solve. If you don't know, then you are blindly patching your DSDT with automated tools for no reason, and that's a bad idea.

 

I see two patches to the LPC device. Are you sure you need both? Are you sure they don't cancel each other out, or conflict somehow?

 

ICH10R needs a LPC device ID patch to get AppleLPC.kext loaded, ICH10 (non-R) does not need it.

http://www.projectosx.com/forum/index.php?...post&p=2532

Link to comment
Share on other sites

remove Alias

Scope (_PR)
{
	Processor (P001, 0x01, 0x00000810, 0x06)
	{
	}
	Alias (P001, CPU1) //delete this line
	Processor (P002, 0x02, 0x00000000, 0x00)
	{
	}
	Alias (P002, CPU2) //delete this line
	Processor (P003, 0x03, 0x00000000, 0x00)
	{
	}
	Alias (P003, CPU3) //delete this line
	Processor (P004, 0x04, 0x00000000, 0x00)
	{
	}
	Alias (P004, CPU4) //delete this line
	Processor (P005, 0x05, 0x00000000, 0x00)
	{
	}
	Alias (P005, CPU5) //delete this line
	Processor (P006, 0x06, 0x00000000, 0x00)
	{
	}
	Alias (P006, CPU6) //delete this line
	Processor (P007, 0x07, 0x00000000, 0x00)
	{
	}
	Alias (P007, CPU7) //delete this line
	Processor (P008, 0x08, 0x00000000, 0x00)
	{
	}
	Alias (P008, CPU8) //delete this line
	Processor (P009, 0x09, 0x00000000, 0x00)
	{
	}
	Alias (P009, CPU9) //delete this line
	Processor (P010, 0x0A, 0x00000000, 0x00)
	{
	}
	Processor (P011, 0x0B, 0x00000000, 0x00)
	{
	}
	Processor (P012, 0x0C, 0x00000000, 0x00)
	{
	}
	Processor (P013, 0x0D, 0x00000000, 0x00)
	{
	}
	Processor (P014, 0x0E, 0x00000000, 0x00)
	{
	}
	Processor (P015, 0x0F, 0x00000000, 0x00)
	{
	}
	Processor (P016, 0x10, 0x00000000, 0x00)
	{
	}
}

and OSID can go Darwin :P

			If (_OSI ("Windows 2006"))
		{
			Store (0x15, Local0)
		}
change to
		If (_OSI ("Darwin"))
		{
			Store (0x15, Local0)
		}

Link to comment
Share on other sites

This was an issue on ASUS boards for a brief period during late versions of 10.5, but as of this version of Chameleon 2.0 RC5 it is no longer necessary to remove CPU aliases (or use a patched BIOS).

 

You're right, the aliases are referred in the SSDT tables and that's why CPUPM stops working if you take them out.

Link to comment
Share on other sites

:wacko:
No. The DSDT table processor declarations are referenced in the SSDT tables, messing with them (renaming, deleting aliases) will break native CPU power management.

Unless you (this is a lot of work for absolutely no benefit, I've been down this road):

Dump your SSDT tables
Change all instances of P00X to CPUX and all references to the CPU aliases in the SSDT tables accordingly
Name the SSDT tables as instructed in the Chameleon topic I linked to earlier
Place them in /Extra
Set DropSSDT=y in org.chameleon.Boot.plist

But there really is no reason to do anything to the processor scope or the SSDT tables. P00x works just as well as CPUx on OS X and aliases are not an issue anymore.

With time I have found it to be more challenging and rewarding to see how little I can modify to get OS X working well, instead of chasing every single possible hack and modification. I put that behind me after having successfully ported Master Chief's P5K Pro DSDT to my P5Q-E. I've never been to war and returned home safely but I guess it must feel a little like I felt at the time.

Thanks to the state of Chameleon, today I can boot and install 10.6.3 on my hardware (P45/ICH10R/Core 2 Duo) using only fakesmc.kext in /Extra! This is impressive and amazing to me considering the hoops we used to have to jump through just a year or two ago.

Link to comment
Share on other sites

You can easily test it yourself without compromising anything, keep your existing DSDT.aml in /Extra and name the new one test.aml. When booting, type DSDT=test.aml at the boot prompt.

 

Install and run IORegistryExplorer from Apple Dev Tools to see if your changes have taken effect.

Link to comment
Share on other sites

 Share

×
×
  • Create New...