Jump to content

DSDT editor and patcher

DSDT editor patcher

  • Please log in to reply
990 replies to this topic

#301
toology

toology

    InsanelyMac Protégé

  • Members
  • Pip
  • 46 posts
  • Gender:Male
  • Location:Serbia
@oldnapalm:

8086;Intel Corporation;2810;82801HB/HR (ICH8/R) LPC Interface Controller;Bridge;ISA bridge

Is this what you need?

#302
kerr

kerr

    InsanelyMac Protégé

  • Members
  • PipPip
  • 94 posts
hey oldnapalm, thanks for usb fix. this solved my longstanding problem with usb drives not working at all after wake. and i had these errors in kernle.log, but no more:

USBF:	62.652	USB (EHCI):Port 1 on bus 0xfa - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 2 on bus 0xfa - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 3 on bus 0xfa - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 4 on bus 0xfa - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 5 on bus 0xfa - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 6 on bus 0xfa - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 1 on bus 0xfd - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 2 on bus 0xfd - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 3 on bus 0xfd - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 4 on bus 0xfd - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 5 on bus 0xfd - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)
USBF:	62.652	USB (EHCI):Port 6 on bus 0xfd - connect status changed but still enabled. clearing enable bit: portSC(0xffffffff)


now i have two more issues:

1. SATA issue. I have two hdds in ports 0 (SL), 1 (win7) and a DVD burner in port 3. But in SL diskutil shows win7 as disk0 and SL as disk1. DVD burner is detected in system profiler but SL shows No Drives. And i have these errors in kernel.log

SerialATAPI device reconfiguration did not complete successfully.  (failedCommandInfo = 0x1)
SerialATAPI device reconfiguration did not complete successfully.  (failedCommandInfo = 0x2)


2. Marvell issue. Have two ethernet controllers from marvell - 88E804X Singleport Copper SA and 88E8053 Singleport Copper SA. the problem is that the system cannot sleep entirely from the first attempt - monitor goes off, but everything else is working. and it gives these errors in kernel.log:

AppleYukon2: 00000000,ffffff806e0ba000 sky2 - HardwareNotResponding, marking offline
AppleYukon2: 00000000,00000000 Yukon2Power - SetWolEnableGPIO - Failed to get ACPI device
AppleYukon2: 00000000,00000000 skqueue - SkEventDispatcher - ignoring event queue, hardware is not responding
AppleYukon2: 00000000,00000000 Yukon2Power - SetWolEnableGPIO - Failed to get ACPI device
System Sleep

but if try again the system goes to sleep normally with fans and power all off. and again error in kernel.log but this time it does't prevent the sleep:

AppleYukon2: 00000000,00000000 Yukon2Power - SetWolEnableGPIO - Failed to get ACPI device
last message repeated 1 time ---
System Sleep


very strange indeed. also i have error in kernel.log form the boot itself:

AppleYukon2 - RomlessInit - getProperty failed

This is it. Can you, please, do something about it ?

EDIT: i forgot to tell you that EthernetBuiltIn-Yes does not solve the problem. In fact ethernet controllers are already shown as Built-in

EDIT 2 : Marvell issue - [SOLVED]; Sleep issue - [SOLVED]

Attached File  dsdt.zip   17KB   8 downloads

#303
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK

EDIT
DualCore and Core2Duo(NoteBook), you do not need anything(Most of them)
just use SMBIOS macbookpro5, 1

MBP5,1
http://www.mediafire...5j07ac5cx27p3ff

I'll try this with and without those solution I mentioned above to see if it makes any difference.

You only need to apply this patch in USB 2.0 device (EHCI). I already put the patch in your DSDT (already combined two patches in one _DSM control method). You just need to change the "AAPL,current-*" values with the one from oldnapalam's post (above). If there are more than one EHCI device in DSDT, clock-id value need to be different. In your case, you only need to change the clock-id value for second EHCI device (EHC1) from 0x01 to 0x02. :wacko:

I checked my EHCI devices and they have the same clock-id, which is 0x0A. I'll change it. May be that's the reason why there are some error messages after wake up.

By the way, I pathced SBUS device with the following code:

Device (SBUS)            {                Name (_ADR, 0x001F0003)                Method (_DSM, 4, NotSerialized)                {                    Store (Package (0x08)                        {                            "name",                             Buffer (0x0D)                            {                                "pci8086,3a30"                            },                             "device-id",                             Buffer (0x04)                            {                                0x30, 0x3A, 0x00, 0x00                            },                             "subsystem-id",                             Buffer (0x04)                            {                                0x70, 0x72, 0x00, 0x00                            },                             "subsystem-vendor-id",                             Buffer (0x04)                            {                                0x86, 0x80, 0x00, 0x00                            }                        }, Local0)                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))                    Return (Local0)                }

IORegisteryExplorer shows that device is loaded.
Attached File  SBUS.jpg   38.96KB   40 downloads

But when I type kextstat I don't see com.apple.driver.AppleSMBusPCI is loaded. I came across this user's post which indicates the same problem and a solution with a new hack. I didn't apply this hack as I don't see any device id etc.

Device (SBUS)            {                Name (_ADR, 0x001F0003)                Device (BUS0)                {                    Name (_CID, "smbus")                    Name (_ADR, Zero)                    Device (DVL0)                    {                        Name (_ADR, 0x57)                        Name (_CID, "diagsvault")                    }                }            }

Can anyone please confirm that com.apple.driver.AppleSMBusPCI should be loaded to be able to say that SBUS device is patched?
What is this I am doing wrong?

#304
kizwan

kizwan

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPipPip
  • 1,422 posts

IORegisteryExplorer shows that device is loaded.
Attached File  SBUS.jpg   38.96KB   40 downloads

But when I type kextstat I don't see com.apple.driver.AppleSMBusPCI is loaded.

Can anyone please confirm that com.apple.driver.AppleSMBusPCI should be loaded to be able to say that SBUS device is patched?
What is this I am doing wrong?

I can confirm AppleSMBusPCI.kext does loaded on my two notebooks (please refer to my signature). I didn't apply SBUS patch since both have vanilla device ID which is 3b30. On my (retired) Acer Aspire 9420, AppleSMBusPCI.kext also loaded.

#305
toology

toology

    InsanelyMac Protégé

  • Members
  • Pip
  • 46 posts
  • Gender:Male
  • Location:Serbia
I am looking into how to change my model identifier to MacPro 3,1 and I came across Beerkex'd guide.

He says to pick identifier closest to your machines hardware. It seems to me my setup is more similar to iMac (current settings probably made by iATKOS S3) because of the Core2Duo and GeForce graphics. In any case his guide is for Leopard, I need to find one for Snow Leopard + Chameleon 2 RC5 :)

#306
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK

I checked my EHCI devices and they have the same clock-id, which is 0x0A. I'll change it. May be that's the reason why there are some error messages after wake up.

I changed the clock-id as you'd suggested but I don't notice any difference in terms of error messages on Console after sleep. Now the compiler reports 39 optimisations, which were 40 before.

I can confirm AppleSMBusPCI.kext does loaded on my two notebooks (please refer to my signature). I didn't apply SBUS patch since both have vanilla device ID which is 3b30. On my (retired) Acer Aspire 9420, AppleSMBusPCI.kext also loaded.

I removed the dsdt code in my previous post and add my SBUS device id to AppleSMBusPCI.kext. SBUS id for my chipset is 2930.

<array>
<string>pci10de,aa2</string>
<string>pci10de,d79</string>
<string>pci8086,3a30</string>
<string>pci8086,2930</string>
</array>

And finally, I patched SBUS device as follows:
Device (SBUS)            {                Name (_ADR, 0x001F0003)                Device (BUS0)                {                    Name (_CID, "smbus")                    Name (_ADR, Zero)                    Device (DVL0)                    {                        Name (_ADR, 0x57)                        Name (_CID, "diagsvault")                    }                }            }
And the kext is loaded.
53	0 0x56450000 0x2000	 0x1000	 com.apple.driver.AppleSMBusPCI (1.0.8d0) <14 5 4 3>


#307
kizwan

kizwan

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPipPip
  • 1,422 posts

I changed the clock-id as you'd suggested but I don't notice any difference in terms of error messages on Console after sleep. Now the compiler reports 39 optimisations, which were 40 before.

Yeah, I read it was the right thing to do (different clock-id for each EHCI devices). I tried to look for the reason why it have to be different but so far I didn't found yet. :P

I removed the dsdt code in my previous post and add my SBUS device id to AppleSMBusPCI.kext. SBUS id for my chipset is 2930.

If you still interested to achieve vanilla setup for SBUS (AppleSMBusPCI.kext), please try change the SBUS patch a little bit where just inject the device-id:-
Device (SBUS)
			  {
				  Name (_ADR, 0x001F0003)
				  Method (_DSM, 4, NotSerialized)
				  {
					  Store (Package (0x02)
						  {
							  "device-id", 
							  Buffer (0x04)
							  {
								  0x30, 0x3A, 0x00, 0x00
							  }
						  }, Local0)
					  DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					  Return (Local0)
				  }
See whether AppleSMBusPCI.kext loaded this time or not. :)

#308
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK

If you still interested to achieve vanilla setup for SBUS (AppleSMBusPCI.kext), please try change the SBUS patch a little bit where just inject the device-id:-

Device (SBUS)
			  {
				  Name (_ADR, 0x001F0003)
				  Method (_DSM, 4, NotSerialized)
				  {
					  Store (Package (0x02)
						  {
							  "device-id", 
							  Buffer (0x04)
							  {
								  0x30, 0x3A, 0x00, 0x00
							  }
						  }, Local0)
					  DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					  Return (Local0)
				  }
See whether AppleSMBusPCI.kext loaded this time or not. :)

Yes, this code works. I don't know how important it is but looking at IORegistryExplorer, when using the new code I shared, there were some extra things showing up for Device (DVL0) and Device (BUS0). Anyway, it loads this way too. Thanks a lot.

@Kizwan, any chance you took a look at HDEF code I shared for a while ago? No sound after sleep issue I told you about.

#309
kizwan

kizwan

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPipPip
  • 1,422 posts

Yes, this code works.

Good to hear it works. I figured maybe susbsytem-id and/or subsystem-vendor-id in earlier patch prevent the device-id injection. You just need to inject device-id 3a30 for AppleSMBusPCI.kext to load.

I don't know how important it is but looking at IORegistryExplorer, when using the new code I shared, there were some extra things showing up for Device (DVL0) and Device (BUS0). Anyway, it loads this way too. Thanks a lot.

SBUS is important for C-State & sleep to work properly. You see those devices (DVL0 & BUS0) because you add this in your DSDT earlier:-
Device (SBUS)
			{
				Name (_ADR, 0x001F0003)
				Device (BUS0)
				{
					Name (_CID, "smbus")
					Name (_ADR, Zero)
					Device (DVL0)
					{
						Name (_ADR, 0x57)
						Name (_CID, "diagsvault")
					}
				}
			}
Try remove it & see whether AppleSMBusPCI.kext still loaded or not. You did removed your device id from AppleSMBusPCI.kext when testing the new patch right?

@Kizwan, any chance you took a look at HDEF code I shared for a while ago? No sound after sleep issue I told you about.

Yes. I already take a look your DSDT & legacy kext. I found your legacy kext a bit different compared to mine (left is yours, right is mine):-
Posted Image
However, I don't think it is the cause of your problem. I believe your problem lies in DSDT, most probably it have to do with _PTS & _WAK control method. I'm not sure what is the best way to fix it but I'll try to look into it again.

#310
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK

Good to hear it works. I figured maybe susbsytem-id and/or subsystem-vendor-id in earlier patch prevent the device-id injection. You just need to inject device-id 3a30 for AppleSMBusPCI.kext to load.

SBUS is important for C-State & sleep to work properly. You see those devices (DVL0 & BUS0) because you add this in your DSDT earlier:-

Device (SBUS)
			{
				Name (_ADR, 0x001F0003)
				Device (BUS0)
				{
					Name (_CID, "smbus")
					Name (_ADR, Zero)
					Device (DVL0)
					{
						Name (_ADR, 0x57)
						Name (_CID, "diagsvault")
					}
				}
			}
Try remove it & see whether AppleSMBusPCI.kext still loaded or not. You did removed your device id from AppleSMBusPCI.kext when testing the new patch right?

Something weird is happening right now. I am pretty sure that when I applied the hack you provided alongside vanilla AppleSMBusPCI.kext, the kext got loaded. I checked again and it was gone. I applied the hack I found and it got loaded again.
I know that those device names appear in IORegistryExplorer because I added them to my DSDT but please take a look at the following screenshots. OSX clearly adds some values to those devices. I can't speak with a scientific mind but if those devices were unnecessary would OSX still assign some values to them?

Notice the PowerManagement section. Now there is a ChildrenPowerState.
Posted Image

Posted Image

Posted Image

Posted Image

Posted Image

May be we could enhance this hack to patch the device id on the fly. The worst case scenario is that I can create a legacy kext.

Yes. I already take a look your DSDT & legacy kext. I found your legacy kext a bit different compared to mine (left is yours, right is mine):-
However, I don't think it is the cause of your problem. I believe your problem lies in DSDT, most probably it have to do with _PTS & _WAK control method. I'm not sure what is the best way to fix it but I'll try to look into it again.

I can't really remember how many DSDT files I downloaded from this forum with hope to fix this problem. Some HDEF codes include something like the following.
OperationRegion (HDAR, PCI_Config, 0x4C, 0x10)
				Field (HDAR, WordAcc, NoLock, Preserve)
				{
					DCKA,   1, 
							Offset (0x01), 
					DCKM,   1, 
						,   6, 
					DCKS,   1, 
							Offset (0x08), 
						,   15, 
					PMES,   1
				}
Some don't. Anyway, I am pretty sure that we'll find a solution. Thanks for your time.

#311
kizwan

kizwan

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPipPip
  • 1,422 posts

Something weird is happening right now. I am pretty sure that when I applied the hack you provided alongside vanilla AppleSMBusPCI.kext, the kext got loaded. I checked again and it was gone. I applied the hack I found and it got loaded again.

Maybe it was unloaded because it is not in use. Try this; apply these patch with vanilla AppleSMBusPCI.kext. Of course removed your device id from it.
SBUS patch (source):-
Method (_DSM, 4, NotSerialized)
				 {
					 Store (Package (0x04)
						 {
							 "name", 
							 Buffer (0x0C)
							 {
								 "pci8086,3a30"
							 }, 
 
							 "device-id", 
							 Buffer (0x04)
							 {
								 0x30, 0x3a, 0x00, 0x00
							 }
						 }, Local0)
					 DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					 Return (Local0)
				 }
BUS0 patch:-
Device (SBUS)
			 {
				 Name (_ADR, 0x001F0003)
				 Device (BUS0)
				 {
					 Name (_CID, "smbus")
					 Name (_ADR, Zero)
					 Device (DVL0)
					 {
						 Name (_ADR, 0x57)
						 Name (_CID, "diagsvault")
					 }
				 }
			 }
I hope AppleSMBusPCI.kext get loaded this time.

I know that those device names appear in IORegistryExplorer because I added them to my DSDT but please take a look at the following screenshots. OSX clearly adds some values to those devices. I can't speak with a scientific mind but if those devices were unnecessary would OSX still assign some values to them?

I'm not sure, maybe Mac OS X automatically assign those values because it detect it's present in DSDT. If you check in windows Device Manager, there is no children device under SMBUS controller. So, BUS0 is only an imaginary devices. :) But as long as AppleSMBusPCI.kext loaded because of it, just keep it in your DSDT. I'm going to apply BUS0 patch in my DSDT too. In MacBookPro6,1 ioreg (to be specific), there is a device called "Mikey" connected to BUS0 under SBUS device.

I can't really remember how many DSDT files I downloaded from this forum with hope to fix this problem. Some HDEF codes include something like the following.

OperationRegion (HDAR, PCI_Config, 0x4C, 0x10)
				  Field (HDAR, WordAcc, NoLock, Preserve)
				  {
					  DCKA,   1, 
							  Offset (0x01), 
					  DCKM,   1, 
						  ,   6, 
					  DCKS,   1, 
							  Offset (0x08), 
						  ,   15, 
					  PMES,   1
				  }
Some don't. Anyway, I am pretty sure that we'll find a solution. Thanks for your time.

I don't think this codes necessary. HDEF patch is simple, just add _DSM control method.

#312
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,836 posts
  • Gender:Male
  • Location:Brazil

@oldnapalm:

8086;Intel Corporation;2810;82801HB/HR (ICH8/R) LPC Interface Controller;Bridge;ISA bridge

Is this what you need?

Yes, please try this
Attached File  dsdt.aml.zip   14.28KB   7 downloads
Remove NullCPUPowerManagement/Disabler/SleepEnabler and set model identifier as MacPro3,1.

#313
Hacktrix2006

Hacktrix2006

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 423 posts
  • Gender:Male
@oldnapalm

Will be reinstalling mac OSX 10.6 tonight to test the lastest file you gave me. Will let you know how it goes.

#314
toology

toology

    InsanelyMac Protégé

  • Members
  • Pip
  • 46 posts
  • Gender:Male
  • Location:Serbia
@oldnapalm

Nevermind that system identifier pm I sent you. I found a barebones plist file for MacPro3,1 and removed the kexts you mentioned. Sleep works!!! No disabler, no sleep enabler and null power needed! You are a genius. :D

#315
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu
I am having a small issue with the DSDT Editor (v0.3). The problem is that I cannot close it. Not by clicking on the red LED. I have to do it from the main menu. Why is that?

Edit: Oops. It's the other way around

Cheers,

Sam.

#316
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,836 posts
  • Gender:Male
  • Location:Brazil
@toology: I'm not saying for sure that using MacPro is better, I just suggested because I use that with a similar mobo and it works, but maybe for a C2D CPU, iMac is a better choice. I would try both models and check temps and frequencies with VoodooMonitor. The video card is something that should be considered too, I believe (AppleGraphicsPowerManagement).

@dutchhockeypro: it's a bug introduced with a change in the last version (association with AML and DSL files in Finder), it will be fixed in the next release, I hope.

@kerr: what's your mobo? Both ethernets are onboard? Can you identify which one causes the errors in log? I never heard of those problems, did a quick search in the forum but found nothing related to DSDT. If you find something please let me know.

#317
slipttees

slipttees

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 343 posts
  • Gender:Male
  • Location:Iguatu-CE, Brazil
Hey, parameter to remove a device and one to add a device anywhere, is it possible?

Remove FDC and add device MCHC in the PCI0 for example.

thx

#318
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,836 posts
  • Gender:Male
  • Location:Brazil
They are available.

into device label FDC remove_entry
into device label PCI0 insert
begin
<device code>
end


#319
slipttees

slipttees

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 343 posts
  • Gender:Male
  • Location:Iguatu-CE, Brazil
owww, big thx Jedi oldnapalm :happymac:

#320
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu

@dutchhockeypro: it's a bug introduced with a change in the last version (association with AML and DSL files in Finder), it will be fixed in the next release, I hope.

Okidoki. Will sit back and relax / wait for the next update. Thanks.

Cheers,

Sam.





Also tagged with one or more of these keywords: DSDT, editor, patcher


1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy