Gigabyte GA-MA770T-UD3P

[makomk]

Ugh. Nightmare. The USB controller in AMD chipset seems to be a buggy piece of garbage that's making me tear my hair out. Every single soft reboot, without fail, it falls over totally. The only way to get it to behave itself again is to power cycle the entire machine - not just soft power off, but physically remove all power. Wish I'd gone with Intel.

[DanL]

I'm not having USB issues with a Biostar AMD 770 board. The USB performance on the SB700 probably isn't as good as some other SB's, but it's good enough for my purposes.

You might also consider an add-in PCI-e USB card.

EDIT: Oh, and have you updated the BIOS?

[Kano]

Better consider e-sata, even usb at fullspeed is slow against that.

[StringCheesian]

Every single soft reboot, without fail, it falls over totally.

Falls over how, exactly? I'm wondering if it is anything I would notice if I were to buy that board.

[monraaf]

I had a similar problem with my Gigabyte board, sometimes attached USB devices were not recognized, the problem disappeared over time, and I haven't seen it for a while. I do have this in my dmesg though:

ehci_hcd 0000:00:12.2: applying AMD SB600/SB700 USB freeze workaround

All I can say is that if you are using a relative old kernel, try a newer one, maybe they fixed your problem in the kernel.

[makomk]

Falls over how, exactly? I'm wondering if it is anything I would notice if I were to buy that board.

Weirdly. Everything's OK at boot, but as soon as I start actually doing anything using USB 2 either the EHCI controller or its Linux driver completely falls over. No communication with existing devices, new devices not detected, etc. (This only happens after a warm reboot, thankfully.) A warm reboot appears to fix things... right up until the point I try to use it again.

I had a similar problem with my Gigabyte board, sometimes attached USB devices were not recognized, the problem disappeared over time, and I haven't seen it for a while. I do have this in my dmesg though:

ehci_hcd 0000:00:12.2: applying AMD SB600/SB700 USB freeze workaround

All I can say is that if you are using a relative old kernel, try a newer one, maybe they fixed your problem in the kernel.

I'm using 2.6.31, which has that workaround, but supposedly the SB700 hardware revision I've got isn't affected by that bug anyway. Not sure if I believe this.

[deanjo]

The errata from AMD still says this from the SB700 series Errata,

Transmission Errors on Packet Identifier May Cause USB® Host Controller To Reinitialize Device

Description:
When receiving a packet identifier (PID) from a USB device while performing asynchronous data transfers, the SouthBridge’s USB host controller may not compare the packet type field to its check bits if the incoming packet type decodes as a STALL handshake. If transmission errors on an incoming packet cause a different packet type field in a PID to match the encoding for a STALL handshake, the SouthBridge may relay the STALL handshake to the application layer instead of ignoring the packet.

Potential Effect on System:
USB host driver software may act on an erroneous STALL handshake and perform a device re-initialization. USB devices should respond to this re-initialization and resume normal operation after a brief delay. If a device is unable to respond correctly to the re-initialization it may disconnect from the host unexpectedly.

Suggested Workaround:
None.

Fix Planned:
Under consideration for a future release.

It's a long time known issue with AMD chipsets and has yet to be resolved. Hopefully they get that fixed in their SB800 series along with their AHCI issues.

[makomk]

The errata from AMD still says this from the SB700 series Errata,



It's a long time known issue with AMD chipsets and has yet to be resolved. Hopefully they get that fixed in their SB800 series along with their AHCI issues.

Doubt it's that errata, since that supposedly just causes unwanted device reconnects. Unfortunately, this controller seems to have a whole bunch of bugs, not all of which are documented and only some of which have been worked around in the Linux kernel. (Just ran across a kernel bugzilla entry for one total-hang wallbanger that was very quietly worked around quite some time ago.)

There's some errata where the "EHCI Dynamic Clock Gating" feature breaks stuff on resume from S4/S5, which I suppose could be what I'm seeing.

[Kano]

Do you use F5D bios?