Jump to content

DSDT editor and patcher

oldnapalm

By oldnapalm,
in Guides

 Share
999 posts in this topic

Recommended Posts

kerr
kerr
Posted
Posted

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]

 

dsdt.zip

Link to comment
Share on other sites
JBraddock
JBraddock
Posted
Posted
EDIT

DualCore and Core2Duo(NoteBook), you do not need anything(Most of them)

just use SMBIOS macbookpro5, 1

 

MBP5,1

http://www.mediafire.com/?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.

post-562417-1285058824_thumb.jpg

 

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?

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
IORegisteryExplorer shows that device is loaded.

post-562417-1285058824_thumb.jpg

 

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.

Link to comment
Share on other sites
toology
toology
Posted
Posted

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 :)

Link to comment
Share on other sites
JBraddock
JBraddock
Posted
Posted
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>

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
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. :)

Link to comment
Share on other sites
JBraddock
JBraddock
Posted
Posted
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.

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
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):-

jbraddockkizwan.jpg

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.

Link to comment
Share on other sites
JBraddock
JBraddock
Posted
Posted
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.

sbus.jpg

 

sbus2.jpg

 

sbus3.jpg

 

sbus4.jpg

 

sbus5.jpg

 

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.

Link to comment
Share on other sites
kizwan
kizwan
Posted
Posted
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.

Link to comment
Share on other sites
toology
toology
Posted
Posted

@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

Link to comment
Share on other sites
oldnapalm
oldnapalm
Posted
  • Author
Posted

@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.

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
Posted
@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.

Link to comment
Share on other sites
kerr
kerr
Posted
Posted
@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.

 

DFI board from my signature. Yes, both are integrated.

 

hmm, i think i solved half of the problem with marvell in the dummiest way possible. After spending whole day (and most of the night apparently) digging the internet, i found that "AppleYukon2 - RomlessInit - getProperty failed" means that OSX cannot read the MAC address correctly because it cannot read the ROM at all. And indeed, look what crazy MAC address OSX gives to 88E804X:

 

AppleYukon2: Marvell Yukon Gigabit Adapter 88E804X Singleport Copper SA
yukon: Ethernet address 00:11:22:33:44:55

 

Now the interesting part: After looking in my board's manual for completely different reason, i noticed that this 88E804X is not 88E804X at all, but Marvell Yukon 88E8052 PCI-E ASF Gigabit Ethernet Controller. This is the correct model number. So it looks like OSX recognizes it wrong and thus creates conflicts. Of course i disabled it and the messages disappeared

 

BUT (oh, how i hate this word !) the bad news is that this does not solve sleeping issue.

 

AppleYukon2: 00000000,00000000 Yukon2Power - SetWolEnableGPIO - Failed to get ACPI device

still prevents the system from sleep in the first attempt.

Link to comment
Share on other sites
oldnapalm
oldnapalm
Posted
  • Author
Posted

Some people inject properties in the LAN device.

 

http://www.insanelymac.com/forum/index.php?showtopic=192518

					Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x02)
						{
							"device-id", 
							Unicode ("*")
						}, Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					Return (Local0)
				}

http://www.insanelymac.com/forum/index.php?showtopic=188920

						Store (Package (0x04)
						{
							"built-in", 
							Buffer (One)
							{
								0x01
							}, 
							"location", 
							Buffer (0x02)
							{
								"1"
							}
						}, Local0)

 

I don't know what they fix, but it may be explained somewhere in the threads.

 

Maybe you need one of those properties, or some other.

Link to comment
Share on other sites
JBraddock
JBraddock
Posted
Posted
Some people inject properties in the LAN device.

I don't know what they fix, but it may be explained somewhere in the threads.

 

Maybe you need one of those properties, or some other.

I applied this hack and my ethernet car is seen as built-in. Also, it gives me an option to boost the speed under System Preferences> Network. I am not sure but it may also fix time machine related problems.

 

Reference Only

Method (_DSM, 4, NotSerialized)
                   {
                       Store (Package (0x08)
                           {
                               "AAPL,slot-name", 
                               Buffer (0x0F)
                               {
                                   "PCI Slot@3,0,0"
                               }, 

                               "built-in", 
                               Buffer (One)
                               {
                                   0x01
                               }, 

                               "device_type", 
                               Buffer (0x09)
                               {
                                   "Ethernet"
                               }, 

                               "name", 
                               Buffer (0x24)
                               {
                                   "Realtek RTL8111/8168B PCI-E Gigabit"
                               }
                           }, Local0)
                       DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                       Return (Local0)
                   }

Link to comment
Share on other sites
kerr
kerr
Posted
Posted

hmm, does OSX makes difference between PCI and PCI Express ? I'm asking because my Marvell is on PCI-E bus 3 (PEX3 device in DSDT) and SL shows PCI only, but recognizes the link as x1 correctly. Does this matter to the OS at all ?

thanks JBraddock, i'll try it though this "PCI Slot@3,0,0" may mess things up. On the other hand i'll try disabling this Marvell too and see if sleep problem has to do anything with ethernet at all....

 

What about my SATA issue ? Do you have any ideas how to fix this ? It is behaves kinda like JBraddock's SMBus (and speaking of his problems it turns out that i have them too - smbus kext is loading whenever it wnats) - it is at different port on every reboot .

Link to comment
Share on other sites
JBraddock
JBraddock
Posted
Posted
hmm, does OSX makes difference between PCI and PCI Express ? I'm asking because my Marvell is on PCI-E bus 3 (PEX3 device in DSDT) and SL shows PCI only, but recognizes the link as x1 correctly. Does this matter to the OS at all ?

thanks JBraddock, i'll try it though this "PCI Slot@3,0,0" may mess things up. On the other hand i'll try disabling this Marvell too and see if sleep problem has to do anything with ethernet at all....

Please take that code as a reference only. It is for my laptop (HDX 16). But I think It would work for HP laptop with ICH9. After applying that you'll get the following option under System Preferences > Network > Ethernet > Advanced > Ethernet. So it is not only cosmetic.

ethernet.jpg

 

What about my SATA issue ? Do you have any ideas how to fix this ? It is behaves kinda like JBraddock's SMBus (and speaking of his problems it turns out that i have them too - smbus kext is loading whenever it wnats) - it is at different port on every reboot .

I don't have SBUS problem anymore with the recent hack that I shared above. Apparently, if your SBUS device id doesn't match with the one in AppleSMBusPCI.kext, you have to add it manually. Normally, injecting device id via DSDT should also work but it doesn't as it is clear in my case. It may be another goodness of 10.6.4.

 

Kizwan shared an another code. I'll try that as well and report back soon.

 

Regarding Sata Device, I've never had a problem with Sata. It's seen as internal and performs well.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...