265 replies to this topic

[KariNeko]

Thanks Master Chief, cVaD & mitch_de for the updated and working version.

[Monkey D. Luffy]

Thanks Master Chief, Cvad, mitch_de .. new version works like a charm

[Bungo]

Hi mitch_de,

Thanks for the updates. I just tried your iASLMe_fixed_march_2010 version and got this error:

Name (_PR0, Package (One)
Invalid object type for reserved name, must be ^  (Package)

I never got it before with your previous versions of iASLMe.
Here is original code where error was found:

Device (FAN0)
		{
			Name (_HID, EisaId ("PNP0C0B"))
			Name (_UID, Zero)
			Name (_PR0, Package (One)
			{
				FN00
			})
		}

[asstastic]

Running the new iasl on 10.5.8 gives the error:

dyld: unknown required load command 0x80000022
Trace/BPT trap

Here's a discussion on the problem:
http://discussions.a...hreadID=2151112

[Master Chief]

Hi mitch_de,

Thanks for the updates. I just tried your iASLMe_fixed_march_2010 version and got this error:

Name (_PR0, Package (One)
Invalid object type for reserved name, must be ^  (Package)

I never got it before with your previous versions of iASLMe. Here is original code where error was found:

Device (FAN0)
		{
			Name (_HID, EisaId ("PNP0C0B"))
			Name (_UID, Zero)
			Name (_PR0, Package (One)
			{
				FN00
			})
		}

And what exactly is FN00? Please attach your DSDT.dsl so that I can have a look at it. Thanks.

[Smith@@™]

The last version "destroys" all my dsdt, this error always:

Invalid object type for reserved name, must be ^

I restore now an old version of iasl and ALL works amazing, same dsdt, nothing error. The problem is SURE last version of iasl, i'm sure

[KariNeko]

I'm having the same problem

/DSDT.test.dsl  5227:						 Name (_PLD, Buffer (0x10)
Error	4080 -										   Invalid object type for reserved name, must be ^  (Package)

The section on the DSDT where it came from look like this

Name (_PLD, Buffer (0x10)
						{
							/* 0000 */	0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
							/* 0008 */	0x30, 0x1C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
						})

[THe KiNG]

New IASL dosen't like optimized DSDT's.
So if you have Zero instead 0x00 or One instead 0x01 or Ones instead 0xFFFFFFFF and so on it will complain.
Funny is that after all are like it ask it does optimize them back on compile LOL.

Another "bug" is on _XYZ Reserved names, if it dosen't know them it will complain again.

Dunno wtf is wrong, or the source is borked or they are going backwards...

BTW if you compile it the decompile and try again you are back with same errors ROFL

[Master Chief]

New IASL dosen't like optimized DSDT's. So if you have Zero instead 0x00 or One instead 0x01 or Ones instead 0xFFFFFFFF and so on it will complain...

This is a regression for which a patch was made available, here even, and thus this should no longer be an issue.

[mitch_de]

Running the new iasl on 10.5.8 gives the error:

dyld: unknown required load command 0x80000022
Trace/BPT trap

Here's a discussion on the problem:
http://discussions.a...hreadID=2151112

iasl was compiled as an 64 Bit app.
Can your "Mac" run 64 Bit Apps ?
64 Bit CPU + mosty Intel needed, i dont know if it will run on AMD, even they are 64 Bit

[rals2007]

iasl was compiled as an 64 Bit app.
Can your "Mac" run 64 Bit Apps ?
64 Bit CPU + mosty Intel needed, i dont know if it will run on AMD, even they are 64 Bit

Using chocolate kernel, it gives me an error regarding arch.
Can you compile it to be 32Bit compatible...Thanks

[THe KiNG]

This is a regression for which a patch was made available, here even, and thus this should no longer be an issue.

Yes I saw that, but Reserved Name bug is not fixed...

/Users/Me/Desktop/test.dsl 10235: Name (_WDG, Buffer (0x50)
Warning 1099 - Unknown reserved name ^ (_WDG)

/Users/Me/Desktop/test.dsl 11468: Method (_WED, 1, NotSerialized)
Warning 1099 - Unknown reserved name ^ (_WED)

[Master Chief]

Yes I saw that, but Reserved Name bug is not fixed...

I am currently looking into it and I will make sure that it get fixed when this 'bug' has been confirmed as bug, but both _WED and _WDG are invalid i.e. unknown to the ACPI 4.0 specification and as such should not be used.

Do you have any other examples [of reserved names] that should be valid? If not then this is not a bug, but a feature [due to stricter checking for typos and other errors].

Thank you.

[tamorgen]

I am currently looking into it and I will make sure that it get fixes when this 'bug' has been confirmed as bug, but both _WED and _WDG are invalid i.e. unknown to the ACPI 4.0 specification and as such not be used.

Do you have any other examples of reserved names that should be valid? If not then this is not a bug, but a feature [stricter checking for typos and other errors].

Thank you.

Master Chief,
I know you are the DSDT guru, so I'm hoping you can answer some questions. No matter what I do, no matter what i use, I cannot get a DSDT to compile. I've tried iASLme, DSDT_patcher, and DSDTSE, and even if all I do is extract, and try to recompile, I get errors.

I have a DSDT that I got from another user that I've been trying to make an edit to. He has the exact same machine, same kexts, but on his laptop, the screen will auto dim when running on battery, mine will not. I found a possible fix, but I cannot get it to compile. Any advise you can give me? I'm getting really frustrated.

Also, I was wondering if the bootloader can cause this sort of behavior? I'm running Chameleon RC5 v112 now. I'm not entirely sure what the other individual is running. He used SnowX86 3.6 to install and doesn't know what bootloader it installed.

[Master Chief]

Master Chief,
I know you are the DSDT guru, so I'm hoping you can answer some questions. No matter what I do, no matter what i use, I cannot get a DSDT to compile. I've tried iASLme, DSDT_patcher, and DSDTSE, and even if all I do is extract, and try to recompile, I get errors.

I have a DSDT that I got from another user that I've been trying to make an edit to. He has the exact same machine, same kexts, but on his laptop, the screen will auto dim when running on battery, mine will not. I found a possible fix, but I cannot get it to compile. Any advise you can give me? I'm getting really frustrated.

Also, I was wondering if the bootloader can cause this sort of behavior? I'm running Chameleon RC5 v112 now. I'm not entirely sure what the other individual is running. He used SnowX86 3.6 to install and doesn't know what bootloader it installed.

Please start a new topic for this issue, and attach the failing DSDT.

[THe KiNG]

I am currently looking into it and I will make sure that it get fixed when this 'bug' has been confirmed as bug, but both _WED and _WDG are invalid i.e. unknown to the ACPI 4.0 specification and as such should not be used.

Do you have any other examples [of reserved names] that should be valid? If not then this is not a bug, but a feature [due to stricter checking for typos and other errors].

Thank you.

Was just a diff b/w last known good version and last one....
I don't care about it since I'm using previous one till Intel will fix own mess.

[tamorgen]

Please start a new topic for this issue, and attach the failing DSDT.

Master Chief,
New post is here. Thanks.

[asstastic]

I run 64bit Win 7 on an Intel Core Duo, so yes it does support 64bit.

iasl was compiled as an 64 Bit app.
Can your "Mac" run 64 Bit Apps ?
64 Bit CPU + mosty Intel needed, i dont know if it will run on AMD, even they are 64 Bit