Friday, March 12th 2021
AMD Fixes Intermittent USB Connectivity Issues on 500 Series Chipsets, BIOS Update Arrives in April
AMD has four weeks ago acknowledged that there was a problem with 500 series motherboard chipsets. The problem has occurred with a few chipset functions like USB connectivity, USB 2.0 audio crackling (e.g. DAC/AMP combos), and USB/PCIe Gen 4 exclusion. To fix these problems, consumers were forced to either put up with problems or lower the PCIe standard from Gen 4 to Gen 3 and switch USB protocol revision from 3.0 to 2.0. This of course wasn't the ideal solution, especially for bandwidth-heavy applications. Users have submitted many reports to AMD, and the company appears to have found a root cause of these issues. AMD has published a Reddit thread, that reports that the company found a solution to the problem and that we are going to see a fix for it in a form in AGESA BIOS update.
Source:
AMD Subreddit
AMD RedditAMD has prepared AGESA 1.2.0.2 to deploy this update, and we plan to distribute 1.2.0.2 to our motherboard partners for integration in about a week. Customers can expect downloadable BIOSes containing AGESA 1.2.0.2 to begin with beta updates in early April. The exact update schedule for your system will depend on the test and implementation schedule for your vendor and specific motherboard model. If you continue to experience intermittent USB connectivity issues after updating your system to AGESA 1.2.0.2, we encourage you to download the standalone AMD Bug Report Tool and open a ticket with AMD Customer Support.
107 Comments on AMD Fixes Intermittent USB Connectivity Issues on 500 Series Chipsets, BIOS Update Arrives in April
Or i820 and the MTH issue which led to a market wide recall of all the chips and boards using it.
Or i850s PCI write delay issue that limited bus bandwidth, or i850's RDRAM null cycle issue where it would prematurely terminate IIO to RDRAM and cause the whole system to lock up.
Or Northwood and the entire SNDS debacle. $400 CPUs falling like flies left and right.
Or how about Mobile 965 Express's IGPU issues.
Or H67/P67's Rev.B SATAII PLL defect?
Maybe want an asterisk on the "always" in your statement there. :)
I mean, it's just dumb to defend any company that sells you products, as there's no such thing as a flawless, faultless, perfect product, even less so when it come to technology.
That said, AMD should really spend a bit more time on getting their platforms ready before they launch them. Hopefully that'll happen with the move to AM5, as they should have a bit more money in their coffers now.
Certainly, and don't confuse that list as defense of AMD. It's entirely to demonstrate Intel's capability to make mistakes. Most recently on that list I could add all the Spectre/Meltdown and now the new ring bus security exploits but honestly those should be fresh in everyone's mind.
Had ZEN2 + B550 for 6 months running PCIe 4.0 graphics, 3200MT XMP had no USB issues. Always on the latest AGESA code.
Since ZEN3 has the same I/O die as ZEN2 I guessing there are a lot of dudes running unstable infinity fabrics and get all sort of anomalies... One of our biggest hardware forums has many ZEN3 owners and there weren't many USB stability complaints or I can't find them... A quick search there from 10.000 comments for "USB" only brings up 71 hits and only one of those had USB2.0 ports going completely inert after flashing a beta ASUS BIOS before it got pulled.
Don't know what they found or how did they fix it, but I'm guessing it must have been some magical combination of hardware and overlocks where the interrupts / signaling on the USB controller got wonky.
Then again, Bug never provided any evidence to support his claim in the first place anyways so you really don't need evidence of absence to dismiss it in the first place. If you can't provide proof to support your own argument, you haven't make a argument in the first place. If you are taking this example and this example only as proof that AMD's platform is inferior, you are making an extremely poor case of it. As other posters have layed out, both companies have had issues in the past.
When you lay things out logically, it doesn't look so silly as "Intel good, AMD trash".
I also remember the USB problems on early Haswell chipsets www.techpowerup.com/182462/intel-fixes-8-series-chipset-usb-3-0-erratum
Better in every way..
I'm not going to say AMD fo life y0 or anything like that.. because if Intel comes back with something that is more enticing of course I will go back.. but for now.. this is alright..
Just need a GPU :banghead:
www.anandtech.com/show/4142/intel-discovers-bug-in-6series-chipset-begins-recall
I think I have that on my Gigabyte X370........unless it's just a crappy DAC/AMP...........which is very possible lol
Why yes.....They are always perfect even in V1
To the guy who'd claimed that Intel is more stable, please furnish proof, just because you'd said so doesn't make it true.:wtf::kookoo:
In all seriousness, though, both companies have their history of fucking up something here or there. No point in getting all defensive for one or the other.
I will take a USB disconnect over bsod anyday. Also seems to be a signal/noise issue, mainly have disconnects on front case ports not rear.
Pcie/gen4 timing bug? I only encounter it on the rig with rtx3xxx. I guess finding this bug in beta would require more gen4 cards for testers lol.
Happy to have a fix, its not a big enough of an issue often enough to roll back to earlier bios.
Zen 2 seemed to have a cleaner launch than Zen 3, stability issues were with those trying to get high IF clocks.
threatpost.com/intel-side-channel-attack-data/164582/
Ring bus timing attack, Appears to have only tested skylake and coffee, Hoping intel can shake these off with Alders lake and on.
Went to the 1155 and found it far more stable than 1366 ever was. 2nd gen 1366 boards were pretty alright, and I had a solid 2p 1366 workstation Z600 that was rock solid. But the consumer boards.... not so great experience.
My first Athlon system: (T-bird 900 Mhz) It kept crashing and then it looked like it possibly was only randomly crashing when idle. The fix was to lower the Vcore, when at stock frequency. Ironically, running a load didn't noticeably make the crashes increase.