GA-MA770-UD3 usb and ahci issues

I have installed the new ga-ma770-ud3 rev 2.0 Although it is a nice board for a good price, it has quite some problems :

1 - Boot from usb device : When installing windows or linux from usb stick, the device first runs in 1.1 mode taking ages to load. Once part of the install is loaded everything speeds up to 2.0 speeds. Very annoying when booting anything from usb

2- AHCI problems : It is impossible to boot from dvd when the drive is in ahci mode, only when you put the dvddrive in ide mode the f12 boot selector will be able to boot from the disk

3- AHCI problems : Booting up with drives in AHCI mode will pause windows startup for more than 20 seconds. This is not the bios startup, this is with the windows logo on screen, (so already loading windows) at that point it will pause for 20 seconds and then continue to boot. No errors / info in the windows event logs

4- AHCI problems : Once you install the newest amd ahci/raid drivers, the pause during windows load goes down from 20 to around 5 seconds. Still freezing up, but only shorter

5- AHCI problems : When waking from S3 sleep, sometimes the drives do not operate for around 20-30 seconds, then the system becomes responsive again.

To sum up, it really only is 100% stable in IDE mode, but come on ahci has been around for years. I am really dissapointed in this motherboard. Is there a solution to the USB / AHCI problems on the horizon ? If not the board is going back.

I do not know this board, and I am no computer expert, but I can make a couple of guesses as to what is happening (and I am guessing!). When a computer starts up, compatibility is everything. Any piece of hardware is not understood by an operating system without loading a driver it will not work until that driver is loaded. That is fine for things like scanners, sound cards and the like that aren't needed to get the operating system running. However, any device that is required for the machine to boot MUST be accessible without a driver, i.e. it has to be directly understood by the kernel. Since it is impossible for a kernel to support huge ranges of hardware without becoming excessively large and vulnerable to attack, the simplest way to ensure compatibility is to run the hardware in a default mode the kernel understands until the drivers are loaded, at which point it switches to its high performance mode. With USB this means running the hardware at the basic level (1.1 or even 1.0) and the boot drive in IDE mode. This would fit with what you are seeing. This certainly would explain the USB behaviour, and covers most of your AHCI issues too. If a DVD drive is set to AHCI mode it cannot be seen by an operating system until the AHCI drivers are loaded. The 20 second pause during windows booting would be the drive switching from IDE to AHCI mode. Also, the newer drivers are probably designed to make the switch more quickly, and when coming out of sleep mode the drives will be in IDE mode when powering up, then switch to AHCI mode once the operating systems begins running, accounting for the delay.

It is also worth bearing in mind the problem may not be entirely down to the motherboard. The hard drives may not be good at switching modes and the drivers may be less than perfect. That said, as a first step I would suggest ensuring your have the latest BIOS for your board installed, ou have the latest drivers for your operating system, and you check your hard drives do not have any known issues or need BIOS updates. Only once everything is fully up to date should you start looking at or for board faults, and if you get to that stage the first thing to do is contact Gigabyte technical support for assistance. They may know about these issues and know how to get rid of them.

Thanks you for your reply, i will contact gigabyte as i know for sure that it is the board : All the components in this build where earlier connected to a asus m3n78-em mainboard with nvidia chipset. That chipset, as does all intel chipsets, do not show this kind of behaviour. I have checked some other forums, and the issue seems to be limited to gigabyte amd chipsets boards.