IntelMausiEthernet.kext for Intel onboard LAN

Mieze · May 2, 2016

@Kynyo: Your DSDT looks like a mess. That's why I still haven't found time to clean it up. I hope ti get it done doing the next days.

Mieze

joevt · May 8, 2016

I've had no problem with the IntelMausi or AtherosE2200 on my GA-Z170X Gaming 7 motherboard so far. There is a minor issue where IntelMausi takes 5 seconds to shutdown but AtherosE2200 does not.

I've connected the built in COM port to another Mac and used the following boot args to output kprintf and IOLog messages over the serial port:

-v dart=0 nvda_drv=1 nv_spanmodepolicy=1 uia_exclude=HS11;HS12;HS13;HS14;USR1;USR2;SS07;SS08;SS09;SS10;HS02 debug=0x108 serial=3 serialbaud=115200 io=0x00200000

Shutdown with just the AtherosE2200 driver looks like this:

backing_store_stop_compaction = TRUE
Kext loading now disabled.
Kext unloading now disabled.
Kext autounloading now disabled.
Kernel requests now disabled.
Process launchd [1] disabling system-wide I/O Throttling
setMulticastList() ===>
setMulticastList() <===
SProcess launchd [1] disabling system-wide CPU Throttling
at May  7 22:40:55 2016 Joes-Giga-Mac.local comProcess mds_stores [183] disabling system-wide I/O Throttling
.Process mds_stores [183] disabling system-wide CPU Throttling
apple.xpc.launchdFailed to send exception EXC_CORPSE_NOTIFY. error code: 5 for pid 75
setMulticastList() ===>
setMulticastList() <===
[1] (com.apple.xpc.launchd.domain.system) <Notice>: System shutdown initiated by: shutdown.446<-sessionlogoutd.445<-launchd.1
 
setMulticastList() ===>
setMulticastList() <===
Sat May  7 22:41:00 2016 Joes-Giga-Mac.local com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system) <Notice>: Userspace teardown took: 5006 ms
 
PMRD: PagingOff all drivers took 0 ms
syncing disks... Killing all processes 
 
continuing
Unmount of /home failed (45)
Unmount of /net failed (45)
hfs: unmount initiated on ElCappy on device unknown device
done
MACH Reboot
[AppleBroadcomBluetoothHostController][SetHIDEmulation] ### ERROR: opCode = 0xFC3B (Broadcom VSC -- Enable HID Emulation) -- send request failed -- err = 0x0001 (kBluetoothHCIErrorUnknownHCICommand)
REQUIRE_NO_ERR failure: 0x1 - file: /BuildRoot/Library/Caches/com.apple.xbs/Sources/IOBluetoothFamily_kexts/IOBluetoothFamily-4404.4.4/Core/Family/HCI/HostControllers/IOBluetoothHostController.cpp:22169
REQUIRE_NO_ERR failure: 0x1 - file: /BuildRoot/Library/Caches/com.apple.xbs/Sources/IOBluetoothFamily_kexts/IOBluetoothFamily-4404.4.4/Core/Family/HCI/Transports/USB/BroadcomBluetoothHostControllerUSBTransport/BroadcomBluetoothHostC
systemWillShutdown() ===>
disable() ===>
Ethernet [AtherosE2200]: Link down on en1
getPacketFilters() ===>
getPacketFilters() <===
txClearDescriptors() ===>
txClearDescriptors() <===
disable() <===
alxLoadDefaultAddress() ===>
getHardwareAddress() ===>
getHardwareAddress() <===
Ethernet [AtherosE2200]: Got MAC address from efuse.
alxLoadDefaultAddress() <===
systemWillShutdown() <===
disable() ===>
**** [IOBluetoothHostControllerUSBTransport][InterruptReadHandler] -- Received kIOReturnAborted error - retrying: 1 -- 0xa800
**** [IOBluetoothHostControllerUSBTransport][InterruptReadHandler] -- failed to post another Read on the interrupt pipe -- error (0xE00002D8 (kIOReturnNotReady)) queueing next read.
**** [IOBluetoothHostControllerUSBTransport][DoDeviceReset] -- thread_call_enter1 (mReEnumerateOrResetThread) -- reEnumerateOrReset = 1 (ReEnumerate Module) --  returned FALSE -- 0xa800 ****
**** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrResetThreadEntry] -- entering -- param0 = 0xa800, param1 = 0x0001 -- 0xa800
**** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrResetThreadEntry] -- exiting -- 0xa800
 
000X8856P9.29355o4 ApPpleUgSBHost:Resosurcesm@: AppleUtdSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 150 sleepUnits 0
X86PlatformPlugin::systemWillShutdown!
000859.310439 AppleUSBHostResources@: AppleUSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 150 sleepUnits 0
000859.324563 AppleUSBHostResources@: AppleUSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 150 sleepUnits 0
000859.336917 AppleUSBHostResources@: AppleUSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 150 sleepUnits 0
000859.349390 AppleUSBHostResources@: AppleUSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 150 sleepUnits 0
PM request 0x6 dropped
PMRD: Restart all drivers took 264 ms

While shutdown with the IntelMausi driver looks like this:

backing_store_stop_compaction = TRUE
Kext loading now disabled.
Kext unloading now disabled.
Kext autounloading now disabled.
Kernel requests now disabled.
Process launchd [1] disabling system-wide I/O Throttling
SProcess launchd [1] disabling system-wide CPU Throttling
at May  7 23:39:41 2016 Joes-Giga-Mac.local com.apple.xpc.launcsetMulticastList() ===>
Process mds_stores [193] disabling system-wide I/O Throttling
Process mds_stores [193] disabling system-wide CPU Throttling
hsetMulticastList() <===
d[1] (com.apple.xpc.launchd.domain.system) <Notice>: System shutdown initiated by: shutdown.535<-sessionlogoutd.in6_unlink_ifa: IPv6 address 0x8beb169cdc837e23 has no prefix
534<-launchd.1
 
hfs: unmount initiated on Empty1 on device disk0s2
hfs: unmount initiated on Empty2 on device disk0s5
setMulticastList() ===>
setMulticastList() <===
Sat May  7 23:39:43 2016 Joes-Giga-Mac.local com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system) <Notice>: Userspace teardown took: 2083 ms
 
PMRD: PagingOff all drivers took 11 ms
syncing disks... Killing all processes 
 
continuing
hfs: unmount initiated on ElCappy on device disk3s2
Unmount of /home failed (45)
Unmount of /net failed (45)
hfs: unmount initiated on ElCapitan on device unknown device
done
MACH Reboot
[AppleBroadcomBluetoothHostController][SetHIDEmulation] ### ERROR: opCode = 0xFC3B (Broadcom VSC -- Enable HID Emulation) -- send request failed -- err = 0x0001 (kBluetoothHCIErrorUnknownHCICommand)
REQUIRE_NO_ERR failure: 0x1 - file: /BuildRoot/Library/Caches/com.apple.xbs/Sources/IOBluetoothFamily_kexts/IOBluetoothFamily-4404.4.4/Core/Family/HCI/HostControllers/IOBluetoothHostController.cpp:22169
REQUIRE_NO_ERR failure: 0x1 - file: /BuildRoot/Library/Caches/com.apple.xbs/Sources/IOBluetoothFamily_kexts/IOBluetoothFamily-4404.4.4/Core/Family/HCI/Transports/USB/BroadcomBluetoothHostControllerUSBTransport/BroadcomBluetoothHostC
**** [IOBluetoothHostControllerUSBTransport][InterruptReadHandler] -- Received kIOReturnAborted error - retrying: 1 -- 0xf800
**** [IOBluetoothHostControllerUSBTransport][InterruptReadHandler] -- failed to post another Read on the interrupt pipe -- error (0xE00002D8 (kIOReturnNotReady)) queueing next read.
**** [IOBluetoothHostControllerUSBTransport][DoDeviceReset] -- thread_call_enter1 (mReEnumerateOrResetThread) -- reEnumerateOrReset = 1 (ReEnumerate Module) --  returned FALSE -- 0xf800 ****
**** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrResetThreadEntry] -- entering -- param0 = 0xf800, param1 = 0x0001 -- 0xf800
**** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrResetThreadEntry] -- exiting -- 0xf800
 
systemWillShutdown() ===>
000868.843144 AppleUSBHostResources@: AppleUSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 150 sleepUnits 0
000868.843189 AppleUSBHostResources@: AppleUSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 150 sleepUnits 0
000868.844816 AppleUSBHostResources@: AppleUSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 150 sleepUnits 0
000868.844838 AppleUSBHostResources@: AppleUSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 150 sleepUnits 0
000868.844869 AppleUSBHostResources@: AppleUSBHostResources::allocateDownstreamBusCurrentGated: assuming successful wakeUnits 150 sleepUnits 0
disable() ===>
Ethernet [IntelMausi]: LPIC=0x11000011.
clearDescriptors() ===>
clearDescriptors() <===
setMulticastList() ===>
setMulticastList() <===
PMRD: Restart still waiting on IntelMausi
Restart still waiting on IntelMausi
Ethernet [IntelMausi]: Link down on en0
getPacketFilters() ===>
getPacketFilters() <===
disable() <===
systemWillShutdown() <===
disable() ===>
PMRD: Restart driver IntelMausi (0x1000002b6) took 5273 ms
X86PlatformPlugin::systemWillShutdown!
X86PlatformPlugin::systemWillShutdown!
PMRD: Restart all drivers took 5469 ms

Both drivers use similar debug messages, so it would be hard to distinguish which driver was doing what if both were enabled at the same time. The messages should probably be prefixed with the driver name.

Mieze · May 8, 2016

I've had no problem with the IntelMausi or AtherosE2200 on my GA-Z170X Gaming 7 motherboard so far. There is a minor issue where IntelMausi takes 5 seconds to shutdown but AtherosE2200 does not.

It's not a bug, it's a feature. The i219 on your board is put into ULP mode when the system shuts down or reboots and the code sequence which enables ULP may poll up to 5 seconds for cable disconnects.

		/* Poll up to 5 seconds for Cable Disconnected indication */
		while (!(er32(FEXT) & E1000_FEXT_PHY_CABLE_DISCONNECTED)) {
			/* Bail if link is re-acquired */
			if (er32(STATUS) & E1000_STATUS_LU)
				return -E1000_ERR_PHY;

			if (i++ == 100)
				break;

			msleep(50);
		}

Mieze

joevt · May 8, 2016

It's not a bug, it's a feature. The i219 on your board is put into ULP mode when the system shuts down or reboots and the code sequence which enables ULP may poll up to 5 seconds for cable disconnects.

Does the same thing happen during kextunload? - there's a 5 second delay then as well.

If the driver knows it's shutting down or being unloaded, then why would it look for cable disconnects?

The code you quoted is surrounded by

if (!to_sx) {
    ...
}

What's to_sx for? Would it be appropriate to set that to true if shutting down or unloading?

Mieze · May 8, 2016

Does the same thing happen during kextunload? - there's a 5 second delay then as well.

Yes, whenever the interface is disabled (sleep without WoL, ifconfig down, shutdown, reboot, unload, etc.) this routine is called.

If the driver knows it's shutting down or being unloaded, then why would it look for cable disconnects?

Because in ULP mode the NIC can't wakeup the machine anymore and even when the driver unloads, the Management Engine (ME) might still need to access it (and it may take control of the NIC while the OS driver doesn't use it ). That's why the driver has to check first.

Personally, I don't understand why you have a problem with the delay at all?

Mieze

joevt · May 9, 2016

Because in ULP mode the NIC can't wakeup the machine anymore

But wakeup is not expected after kextunload or system shutdown. If the kext is reloaded or another kext is loaded, then it will take the NIC out of ULP mode, and wakeup will work again, right?

and even when the driver unloads, the Management Engine (ME) might still need to access it (and it may take control of the NIC while the OS driver doesn't use it ). That's why the driver has to check first.

You're saying the ME is waiting for the kext to unload or shutdown (or link is not up status), so the kext can't put it in ULP mode right away, because the ME won't be able to access it in that case (won't be able to change the status to link is up), but the ME only gets 5 seconds to take over, otherwise it can't ever take over?

The function has a comment: "If on a Manageability Engine (ME) enabled system, tell the ME firmware to start the ULP configuration." The function has a test:

	if (er32(FWSM) & E1000_ICH_FWSM_FW_VALID) {
		/* Request ME configure ULP mode in the PHY */
		...
		goto out;
	}

which skips the 5 second delay. Is that a different ME than the one you're talking about? I guess anything could set the link is up status, not just the ME?

Personally, I don't understand why you have a problem with the delay at all?

Shutdown or unload is an important part of the kext lifecycle that sometimes doesn't get enough attention. I feel that any human perceivable delay might point to other problems so I had to bring it up. You say it's not a problem (thanks for checking) so we can leave it at that.

Mieze · May 9, 2016

But wakeup is not expected after kextunload or system shutdown. If the kext is reloaded or another kext is loaded, then it will take the NIC out of ULP mode, and wakeup will work again, right?

You're saying the ME is waiting for the kext to unload or shutdown (or link is not up status), so the kext can't put it in ULP mode right away, because the ME won't be able to access it in that case (won't be able to change the status to link is up), but the ME only gets 5 seconds to take over, otherwise it can't ever take over?

The function has a comment: "If on a Manageability Engine (ME) enabled system, tell the ME firmware to start the ULP configuration." The function has a test:
	if (er32(FWSM) & E1000_ICH_FWSM_FW_VALID) {
		/* Request ME configure ULP mode in the PHY */
		...
		goto out;
	}
which skips the 5 second delay. Is that a different ME than the one you're talking about? I guess anything could set the link is up status, not just the ME?

Shutdown or unload is an important part of the kext lifecycle that sometimes doesn't get enough attention. I feel that any human perceivable delay might point to other problems so I had to bring it up. You say it's not a problem (thanks for checking) so we can leave it at that.

What exactly the ME does, depends on the system's configuration and is in large parts a secret of Intel but as a driver programmer you have to take into account that you are not in full control of the NIC so that cooperation with the ME is mandatory. This code sequence is part of Intel's linux diver and they probably had a reason to do it this way. Removing the delay might have negative side effects we don't know.

Mieze

sigmaris · May 14, 2016

Hi Mieze, first I want to say thanks for your work on this driver, and also on your Realtek 8111 driver which I previously used with my old motherboard.

My request is: Is there any way to permit wake-on-LAN after shutdown when using this driver? I dual boot Windows + Yosemite, and sometimes I want to shut down my computer, and wake it remotely later when I'm at work or similar, using wake-on-LAN. This works fine if I shut down from Windows, but if I shut down from Yosemite, it never wakes on LAN. I guess it's because your driver fully shuts down the NIC when Yosemite shuts down, and the Windows driver doesn't.

Is there a configuration option to keep the NIC able to wake-on-LAN when the computer is shut down from Yosemite? I know it's not officially supported by OS X, but it must be possible somehow because I had a Realtek 8111 NIC before which would work OK in this situation, in Yosemite. Now I have to restart the computer from Yosemite and then shut it down with the power button while it's at the Clover screen, to work around this and make it wake-able when shutdown.

I have an onboard I217V on a GA-Z97-UD3H motherboard.

Mieze · May 14, 2016

Unfortunately there is no save way to make it work because OS X doesn't support WoL from S5 and implementing it anyway may have unwanted side effects, e.g. a reboot when trying to shutdown your machine making proper shutdown impossible. Sorry!

Mieze

Mieze · May 24, 2016

I finally decided to make version 2.1.0d5 the official release version 2.1.0 and updated the prebuilt binary in the download section.

Mieze

calibre™ · May 25, 2016

Hi Mieze

What is the min OS build for this?

Mieze · May 25, 2016

Hi Mieze

What is the min OS build for this?

El Capitan and later.

Mieze

dragonmel · June 10, 2016

Meize

your skills and expertice in osx networking never fail to astound.

I looked into your intelmausi kext for my DX58so board which runs a intel 82567LM-2 based onboard nic.

accoding to the code on you download site, it supports the chipset but your development does not list it..

I was using appleintel1000e but it was giving me some issues so I downloaded your latest built kext, added my dev id 8086 10cc I think it was, and gave it a try

lockups, finder hangs.. not getting anywhere...

First question, can i get your driver to work with this chipset?

If not, is the latest 3.3.3 of appleintel1000e the best way to go for this chip? any other suggestions for dsdt edits or stack tuning>?

also, I have a S5520HC intel server board with dual 82575EB copper nics.. currently using appleigb is that the way to go, and same question, any configs or tuning there.

on this board I am leaning heavily toward running esxi and just putting osx into a VM .. any issues there or does vmtools do a good job for their virtual 1000e driver.. no vmxnet3 driver for osx unfortunately

Thanks!!!

update..

I found that hnak's 1000e is now 3.3.3 and it works a bit better than the old on my DX58so.. but throughput for large media should be better... and it sounds like your driver enables more feautures of the stack... if it works for my chipsets...

Mieze · June 10, 2016

I looked into your intelmausi kext for my DX58so board which runs a intel 82567LM-2 based onboard nic.

accoding to the code on you download site, it supports the chipset but your development does not list it..

Although the driver doesn't support these old NICs officially, I haven't removed the code to support them, only the chip's PCI device IDs in the Info.plist file is missing which means that there is a chance to make it work by adding the missing IDs to the Info.plist file. Provided there are no bugs which prevent it from working with these old chips, you might be lucky.

Mieze

dragonmel · June 10, 2016

can you elaborate on the two chipsets that I am usings if you feel that your code is a good canditate or not?

also, what DSDT edits are you refering to?

I tried your code on my DX58so with the intel 8086 10cc 82567LM-2 and got hangs, finder hangs, basically didnt work. followed your install instructions and also manually configured the nic settings not enabling flow control didnt help..

the new 3.3.3 seems to work a bit better but if I can get your code working for this board I am sure yours is better...

I can upload my dsdt if it would help or drop it in your dropbox

thanks

cs45 · June 11, 2016

Hi Mieze,

Thanks for the great work on the driver.

I'm experiencing an issue with the interface going down during large data transfers.

For example, copying 200 GB over the network from a GA-H170N hackintosh server using an Intel i219 Ethernet port to an iMac client. After a 5-10 mins the interface goes down and keeps on resetting itself, and I’m only able to fix the problem with a reboot. This only happens when transmitting data from the hackintosh to the iMac, not the other way around.

I configured the interface manually using 1000BaseT, no flow-control or EEE. I installed the debug version of IntelMausiEthernet V2.1.0.

The following message shows up in the log:

6/11/16 11:11:19.000 AM kernel[0]: Ethernet [intelMausi]: Check tx ring for progress. txNumFreeDesc=502
6/11/16 11:11:20.000 AM kernel[0]: Ethernet [intelMausi]: Tx stalled? Resetting chipset. txDirtyDescIndex=946, STATUS=0x40080083, TCTL=0x3103f0fa.
…
[see attached log.rtf for more details]

Thanks for your help.

cs45

Log.rtf

Mieze · June 18, 2016

The SSDT-patch is obsolete.

Mieze

Edited September 20, 2016 by Mieze

MilesTEG1 · June 24, 2016

Hello Mieze,

I just checked something on my Hackintosh : the transfert rates on my I218-V ethernet card (for my Haswell-Refresh CPU i5-4690K).
And I see that when I'm on OS X (here El Capitan 10.11.5), i can grab a file from my NAS (Synology DS214lay) at a max of 16 Mo/s. But when i'm on windows 10, the transfer rates grow up to 60 Mo/s... for the same big file (severals Go).

Does the problem of C7 states for Haswell CPU also apply to my Haswell-Refresh CPU ??

I don't see another problem, no crash when transferring a file, just the low transfert rate.

I don't have any patch to my DSDT because I don't know how to do this.

Your kext is installed on /S/L/E/.
I try severals versions of the drivers : 2.1.0 ; 2.1.0d5 ; 2.0.2d3 ; 2.0.2d5. And with all it's the same.

When I try the transfer, I check if another transfer is currently doing, but no other one.

Is there anything to do to get better transfert rates?

Thanks for your help.
Miles

Fljagd · June 24, 2016

@MilesTEG1

Salut

In the network settings

MilesTEG1 · June 24, 2016

@MilesTEG1

Salut

In the network settings

Hello salut

I try this setting, but it's the same. 16Mo/s with OSX...

Fljagd · June 24, 2016

Hello salut

I try this setting, but it's the same. 16Mo/s with OSX...

That might be a cable problem

mine is a Category 7 (1000 MB / s)

MilesTEG1 · June 24, 2016

That might be a cable problem

mine is a Category 7 (1000 MB / s)

It cold be a cable problem if under windows I've got the same transfer rate... But founder windows, I have 60 Mo/s !

So it's not a cable problem I think.

Fljagd · June 24, 2016

then a last option
my kext is not in S / L / E but in EFI / CLOVER / kexts / 10.11

MilesTEG1 · June 24, 2016

then a last option

my kext is not in S / L / E but in EFI / CLOVER / kexts / 10.11

I can try to pu the kext in /EFI/Clover. But I don't think it will change anything.

I try, reboot, and tell you.

As I suspected, It doesn't change anything.

Mieze · June 24, 2016

Hello Mieze,

I just checked something on my Hackintosh : the transfert rates on my I218-V ethernet card (for my Haswell-Refresh CPU i5-4690K).

And I see that when I'm on OS X (here El Capitan 10.11.5), i can grab a file from my NAS (Synology DS214lay) at a max of 16 Mo/s. But when i'm on windows 10, the transfer rates grow up to 60 Mo/s... for the same big file (severals Go).

Does the problem of C7 states for Haswell CPU also apply to my Haswell-Refresh CPU ??

I don't see another problem, no crash when transferring a file, just the low transfert rate.

I don't have any patch to my DSDT because I don't know how to do this.

Your kext is installed on /S/L/E/.

I try severals versions of the drivers : 2.1.0 ; 2.1.0d5 ; 2.0.2d3 ; 2.0.2d5. And with all it's the same.

When I try the transfer, I check if another transfer is currently doing, but no other one.

Is there anything to do to get better transfert rates?

Thanks for your help.

Miles

Performance issues may have several reasons:

Every protocol implementation has it's own characteristic behavior, with certain parameters (some of them can be changed easily, while others are fixed) which differ from those of other implementations and sometimes you might end up with a combination that doesn't get well with each other. In many cases changing some parameters solves the problem but in others it's just bad luck. Unfortunately it's not easy to find out which parameter is the limiting factor.
Take into account that the reason for the problem may be found on the other communication endpoint, i.e. the NAS, it's not alywas the Mac.
Power management's influence on I/O performance is indisputable and it tends to get worse with a fast CPU. In fact even under Windows one NIC may exhibit significant differences with regard to LAN performance depending on the mainboard's power management as you can see in this chart(sorry, German but the numbers should be readable for everybody) http://www.computerbase.de/2014-12/z97-mainboard-vergleichstest-asus-msi-gigabyte-asrock/8/
Performance issues with SMB under OS X have a long history and it shouldn't be hard to find some hints about the parameters which can be tuned tin order to improve throughput.

Mieze

IntelMausiEthernet.kext for Intel onboard LAN

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites