Thanks for the extra info Slider, very interesting and maybe usefull if accurate. It must have taken a bit of digging to find some of that though. 
I've been trying to figure out the "black screen" lockup when resuming from sleep with this motherboard for about a week and I've been reading just about everything I can find on the motherboard. I can't guarantee the accuracy of my information, but it is my "best understanding" currently and is based on a lot of reading (and discounting LOTS of inaccurate information being posted everywhere). Most of the information on the PCIe 1.0 x1 bus vs PCIe 2.0 x8 bus switch was from reviews on Anandtech and Toms Hardware. I can't recall which site was sent the updated firmware, driver and MRU from Gigabyte, but I believe it was NOT Anandtech nor Toms Hardware.
One fact that you omitted is that the Marvell contoller chip doesn't pass on the TRIM commands to the SSD anyway so that is another good reason not to use it for them. There have been several Marvell firmware updates and new drivers since inception but none seem to have had any real impact on the perfomance.
I actually left that out deliberately because there seems to be a lot of confusion as to if TRIM is or is not supported. I have read several times that TRIM
is supported with the last two revisions of the Marvell driver and newer firmware as well as when the MS ACHI driver is used; although I have also read that even though it is supported, some argue that it still doesn't work properly. Some of the comments claiming that it does work include images showing the results of test software that states it DOES work so this makes me more inclined to believe that it at least partially does support TRIM. On the other hand, other discussions have many comments where people say it doesn't work at all so I'm not sure if it really does or doesn't.
I wish Gigabyte would take an interest in these issues and include in their motherboard FAQ if the SATA 6G ports (Marvell 9128 controller) properly support SSDs (TRIM support, etc.) as well as include information on what driver is best to use for which scenario (perhaps MS ACHI for SSDs and Marvell driver for 6G hard drives for example?) Note I'm not saying this is the best configuration at all; one would "hope" that just using the latest Marvell driver would be the best - of course Gigabyte would then actually have to include the driver on their download pages...
As I mentioned before I was not able to get Windows 7 to install when I had the two Seagate SATA 3G drives connected to the Marvell controller. I tried using both Microsoft's own built in driver as well as the Marvel 9218 driver version 1.0.0.1036. I used the BIOS to configure the drives in a RAID 0 and attempted to install Windows 7 64-bit on the RAID. The RAID 0 was detected during the install, but the drive kept "disappearing" or I would experience a BSOD during the install or during the very first boot. Unfortunately I did not try enabling "Turbo SATA" in the BIOS (at the time I didn't understand it was required in order to support the throughput for the RAID 0 and this may have been the reason for the failure). I also did not try the newer Marvell controller driver (latest I'm aware of is 1.0.0.1051 and can be downloaded from
http://www.station-drivers.com/page/marvell.htm). It might be worth trying to enable Turbo SATA as well as use the latest driver. This might allow Windows 7 to install on a RAID 0 on the Marvell 9128 controller.
To elaborate a little on the Turbo SATA BIOS setting and why not using it might "cause" the data corruption and BSODsg... When it is not used, the Marvell controller is connected through a PCIe 1.0 x1 bus with a total maximum directional throughput of 250 MB/s. By the time overhead and other inefficiencies are included this drops down to around 150 MB/s (based on me trying a pair of high speed drives now that the OS is installed and only seeing 150 MB/s instead of 250+ MB/s like the Intel SATA controller does; there were also lots of I/O errors reported in the event log and the system kept "pausing", like it does when attempting to handle disk I/O errors). Since the pair of drives in RAID 0 had a throughput that is higher than the bus, the Marvell controller would need to handle some form of handshake flow control with the PCIe bus. One possibility for the data corruption, BSODs and crashes is that flow control through the bottle-necked PCIe bus is not handle properly and data is lost. Perhaps there is no flow control at all and the extra data is simply lost, without an adequate buffer. Once the Turbo SATA setting is configured in the BIOS the Marvell controller now connects using a 4000 MB/s PCIe 2.0 x8 bus. The Marvell controller should now be able to pump data through the bus without worrying about flow control and this might resolve the data corruption issue.
I might give this a try, but if any of you have a chance to test it before me please post your results here. It would be nice to discover that using the combination of the Turbo SATA option in the BIOS and the latest Marvell controller driver provides reliable SATA 6G performance (since we did pay for this when we bought our motherboards). I am also very interested in knowing the burst I/O performance to a pair of 6 Gb/s SATA drives in RAID 0. If the Marvell controller actually works properly we should see numbers in the 1000-1500 MB/s range in theory.
