AMD AM5 motherboard problems
USB 3.2 Gen 2 not working, DDR5 troubles
In December 2024 I built myself a new PC. Some of the specs are:
- Motherboard: Gigabyte B650m Aorus Elite Ax
- RAM: G-Skill Trident Z5 DDR5-7200 2x24GB CL36
- Processor: AMD Ryzen 9 9900X
- Case: Fractal Pop Mini Air
The first problem (warm-up)
Right out of the box, the new Ryzen 9 CPU wasn't supported by the motherboard. So after putting everything in place I updated the BIOS with a USB stick. The motherboard flashed its LEDs and seemed like it did something, but when I powered it on, an ominous DDR error diagnostics LED was shining.
I found an interesting thread online about that. People had solved their problems in different ways, ranging from wiggling the CPU to waiting a couple of nights. Well I did everything, even the silliest of things people suggested in the thread, until, after a few days of waiting and trying, I took the parts to a friend of mine. We cross-tested RAM sticks and my CPU. Everything seemed to work.
I was about to RMA the motherboard when I decided to try the BIOS update one more time, this time with the CPU removed from its socket. Lo and behold, after this the computer booted. So, if you ever do a "BIOS update without a processor", you might actually have to do it literally without the processor.
The USB problem
The Fractal case has a placeholder for a front-panel USB-C connector. Since the Gigabyte B650m Aorus Elite Ax says it supports 20 Gbps (USB 3.2 Gen 2 2x2) connectors, I bought a rather expensive 20 Gbps header cable. However, the front USB was not working correctly.
USB 3.2 Gen 2 USB-C front header "not working"
A sad story followed with the high-speed front-panel USB-C header. My 10 Gbps external USB-C backup SSD was detected but couldn't be mounted. The kernel log was full of errors such as these:
[ 109.934362] sd 7:0:0:0: [sdb] Attached SCSI disk
[ 136.959168] EXT4-fs (dm-2): mounted filesystem d085f213-4ab5-433c-b160-b5ca12895d8d r/w with ordered data mode. Quota mode: disabled.
[ 185.408430] sd 7:0:0:0: [sdb] tag#22 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
[ 185.408436] sd 7:0:0:0: [sdb] tag#22 CDB: Read(10) 28 00 92 41 e3 90 00 00 08 00
[ 185.408438] sd 7:0:0:0: [sdb] tag#8 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD
[ 185.408439] sd 7:0:0:0: [sdb] tag#8 CDB: Read(10) 28 00 92 40 a2 a8 00 00 08 00
[ 185.408440] sd 7:0:0:0: [sdb] tag#7 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD
[ 185.408441] sd 7:0:0:0: [sdb] tag#7 CDB: Read(10) 28 00 92 40 a2 a0 00 00 08 00
[ 185.408442] sd 7:0:0:0: [sdb] tag#6 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD
[ 185.408443] sd 7:0:0:0: [sdb] tag#6 CDB: Read(10) 28 00 92 40 a2 98 00 00 08 00
[ 185.418433] scsi host7: uas_eh_device_reset_handler start
[ 185.655526] usb 6-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[ 185.667028] scsi host7: uas_eh_device_reset_handler success
[ 216.640430] sd 7:0:0:0: [sdb] tag#29 uas_eh_abort_handler 0 uas-tag 18 inflight: CMD OUT
[ 216.640436] sd 7:0:0:0: [sdb] tag#29 CDB: Write(10) 2a 00 12 b0 b2 98 00 02 00 00
--
[ 364.267278] sd 7:0:0:0: [sdb] tag#16 uas_zap_pending 0 uas-tag 30 inflight: CMD
[ 364.267279] sd 7:0:0:0: [sdb] tag#16 CDB: Write(10) 2a 00 12 c8 08 00 00 04 00 00
[ 364.379541] usb 6-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[ 364.391038] scsi host7: uas_eh_device_reset_handler success
[ 364.391219] sd 7:0:0:0: [sdb] tag#24 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=30s
[ 364.391220] sd 7:0:0:0: [sdb] tag#24 CDB: Read(10) 28 00 8f c0 a1 00 00 00 70 00
[ 364.391220] I/O error, dev sdb, sector 2411766016 op 0x0:(READ) flags 0x80700 phys_seg 14 prio class 0
--
[ 424.824702] sd 7:0:0:0: [sdb] tag#23 uas_zap_pending 0 uas-tag 29 inflight: CMD
[ 424.824703] sd 7:0:0:0: [sdb] tag#23 CDB: Read(10) 28 00 92 42 2d b8 00 00 08 00
[ 424.936521] usb 6-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[ 424.948028] scsi host7: uas_eh_device_reset_handler success
[ 426.720455] sd 7:0:0:0: [sdb] tag#24 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=62s
[ 426.720460] sd 7:0:0:0: [sdb] tag#24 CDB: Read(10) 28 00 8f c0 a1 78 00 00 90 00
[ 426.720461] I/O error, dev sdb, sector 2411766136 op 0x0:(READ) flags 0x80700 phys_seg 18 prio class 0
--
[ 879.162202] sd 7:0:0:0: [sdb] tag#22 timing out command, waited 180s
[ 879.162203] sd 7:0:0:0: [sdb] tag#22 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK cmd_age=188s
[ 879.162205] sd 7:0:0:0: [sdb] tag#22 CDB: Write(10) 2a 00 78 d1 81 00 00 04 00 00
[ 879.162205] I/O error, dev sdb, sector 2026995968 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[ 879.162216] sd 7:0:0:0: [sdb] tag#23 timing out command, waited 180s
[ 879.162217] sd 7:0:0:0: [sdb] tag#23 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK cmd_age=188s
[ 879.162218] sd 7:0:0:0: [sdb] tag#23 CDB: Write(10) 2a 00 78 d1 85 00 00 04 00 00
[ 879.162218] I/O error, dev sdb, sector 2026996992 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[ 879.162221] EXT4-fs warning (device dm-2): ext4_end_bio:342: I/O error 10 writing to inode 76159356 starting block 253370336)On Windows a similar result was observed: I could perhaps just about read the drive for a second or two, but then it would error. Here is a longer example kernel log file taken using an Asus TUF GAMING B850M-PLUS WIFI motherboard with the B850 chipset.
Again I took the header cable to my friend and it worked just fine on his computer. Then I found this Reddit thread. It seemed that a lot of people had random problems with the front USB-C header "not working", whatever that means.
Since, thanks to the Reddit thread, I thought it was just the front USB header that wasn't working, and it didn't even occur to me to test the rear USB ports first, I decided to buy adapter cables to make a front-panel USB-C connector from one of the motherboard's rear USB ports. The magnitude of my surprise was only matched by my disappointment when I realized that the problem still persisted. And it wasn't the cables: on my Lenovo T14s work laptop, the cables worked with the promised 10 Gbps speed just fine.
The real problem and solution
The USB problems, the RAM sticks' inability to achieve stable speeds, and a bit of bad luck resulted in me buying two more motherboards, both using the practically same but a bit newer B850 chipset. I kept encountering the same USB problems. It took me some time to figure out what's really happening.
It seems that the USB protocol for accessing the external SSD does not work above 5 Gbps speeds if the driver is UAS (USB Attached SCSI). My external SSD is 10 Gbps and the kernel loads the UAS driver automatically for it.
To see what driver is in use, use lsusb -t:
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
|__ Port 004: Dev 003, If 0, Class=Mass Storage, Driver=uas, 10000MThis thread tells about a guy who went the distance to explain the problem to AMD and got back pretty much just ridicule and denial. There seems to be only a handful of people in the whole world who understand what is actually happening. Eventually, the guy ended up switching all his systems to Intel. It's worth noting that the issue seems to concern even AM4 platforms.
The same was true in my case: on my Intel work laptop, the UAS driver and external SSD worked just fine. However, all my AMD motherboards (Gigabyte, Asus, ASRock) failed. I am quite confident that a lot of the people who have had random trouble of the front USB-C "not working" have actually bumped into the same issue, they just haven't realized it. I say this because the front USB-C port is the most obvious place to plug in an external SSD.
When executing lsusb, I got this device for my external USB storage drive:
ID 152d:0562 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridgeThe solution for me was to force the slower usb-storage driver in use for my external USB drive by creating a file /etc/modprobe.d/disable-uas.conf with contents:
options usb-storage quirks=152d:0562:uAfter recreating the initramfs with dracut I now had usb-storage as the driver:
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
|__ Port 004: Dev 003, If 0, Class=Mass Storage, Driver=usb-storage, 10000MSince the drive worked with the faster UAS driver with my Intel laptop, it does seem like UAS on AMD is broken at least with some hardware combinations. I'm now on my fourth motherboard and with it the UAS driver finally seems to work. I'm not sure what finally fixed the issue, as the chipset is still the same B850.
DDR5 problems and stress-testing
The problems didn't end there. My computer experienced random freezes every now and then.
At one point I realized I could reliably freeze my computer by starting a virtual machine. I figured there must be something wrong with the hardware, and RAM was the first suspect. So I tried to lower the speeds from XMP to JEDEC, from 7200 MHz to 5600 MHz. And it helped, the virtual machines started working again.
I always stress-test my new computers thoroughly to avoid any weird problems later on. This time was no exception: I had run Prime95 and memtest86+ overnight with zero errors. Yet, I seemed to have speed-related memory problems.
Searching the Internet, I found out about y-cruncher, especially its tests 15-18. This is how the y-cruncher's user interface looks like:
Component Stress Tester
1 Logical Cores: 24
2 Memory: 40.8 GiB ( 1.70 GiB per thread )
3 NUMA Mode: Local - Memory allocated from local thread.
4/5 Time Limit: 120 seconds per test / Run Forever
6 Stop on Error: Enabled
7/8 Enable All Tests / Disable All Tests
9/10 Load/Save Configuration File
# Tag Test Name Mem/Thread Component CPU------Mem
11 BKT Basecase + Karatsuba Disabled Scalar Integer -|--------
12 BBP BBP Digit Extraction Disabled AVX512 Float |---------
13 SFTv4 Small In-Cache FFTv4 Disabled AVX512 Float -|--------
14 SNT Small In-Cache N63 Disabled AVX512 Integer --|-------
15 SVT Small In-Cache VT3 11.1 MiB AVX512 Integer --|-------
16 FFTv4 Fast Fourier Transform (v4) 246 MiB AVX512 Float ---------|
17 N63 Classic NTT (v2) 1.70 GiB AVX512 Integer ------|---
18 VT3 Vector Transform (v3) 1.69 GiB AVX512 Integer -------|--
0 Start Stress-Testing!I left the computer running at a certain RAM frequency and checked in the morning whether an error had occurred and how long the test had run before it stopped. I kept the RAM timings intact, so at lower frequencies, the timings were easier to meet. The results surprised me:
- 7200 MHz: around 30 minutes
- 6800 MHz: around 90 minutes
- 6400 MHz: around 4 hours
- 6200 MHz: around 8 hours
- 6000 MHz: around 9 hours
- 5600 MHz (JEDEC): around 9.5 hours
- 5400 MHz: around 10 hours
- 5200 MHz: no error
The error message was always something along these lines:
Iteration: 54 Total Elapsed Time: 26116.914 seconds ( 7.255 hours )
Running SVT: Passed Test Speed: 4.2 * 10^10 bits / sec
Running FFTv4: Passed Test Speed: 2.47 * 10^09 bits / sec
Running N63: Passed Test Speed: 1.08 * 10^10 bits / sec
Running VT3: Passed Test Speed: 1.32 * 10^10 bits / sec
Iteration: 55 Total Elapsed Time: 26600.577 seconds ( 7.389 hours )
Running SVT: Passed Test Speed: 4.21 * 10^10 bits / sec
Running FFTv4: Passed Test Speed: 2.47 * 10^09 bits / sec
Running N63: Passed Test Speed: 1.07 * 10^10 bits / sec
Running VT3:
Exception Encountered: ConvolutionFailedException
Coefficient is too large.
Error(s) encountered on logical core 12.
Running VT3: Failed Test Speed: 1.31 * 10^10 bits / sec
Error encountered. Total Elapsed Time: 26600.577 seconds ( 7.389 hours )
So, my memory, which was specified to work at 7200 MHz, didn't even work at its JEDEC frequency of 5600 MHz. I tried limiting the SOC voltage to 1.2 V as motherboard manufacturers apparently often bump it all the way to 1.35 V for XMP profiles, but 1.2–1.25 V is apparently what AMD recommends as the most stable range, at least according to the grapevine. This had no effect, though. And the worst part: I did already have one random freeze in practical use with the seemingly stable memory speeds.
Eventually I switched to an ASRock motherboard where I could get the memory running stable 6200 MHz with tight timings. Later on, I switched to an Asus motherboard, where I was finally able to achieve stable XMP settings at 7200 MHz. I just need to have Gear Down Mode enabled.
DDR5 stability seems to depend on the CPU, the motherboard, and the memory sticks. Any of those might be the cause if RAM errors are the symptom. Therefore it's really hard to RMA a DDR5-based part if mysterious errors occur. It's a bad situation for consumer rights: one can never know what the problem really is, and without spare parts, it might be impossible to figure out the real culprit.
One thing and the point of this part of the rant is for sure: memtest86+ and Prime95 are a complete waste of time for testing memory stability on DDR5. You could run them around the clock for days on end with no errors, where 20 minutes on y-cruncher would reveal instability already. Prime95 does reveal stability issues with the Infinity Fabric clock speed, though. What is very unfortunate is that many companies running the RMA processes test the parts simply by running memtest86+. Therefore, they might never reproduce the issue you might be having.
The final problem: ASRock motherboard killed the CPU
After the Gigabyte I bought an Asus TUF GAMING B850M-PLUS WIFI. The board was stress-test stable with the XMP memory profile. Unfortunately it had not only the same UAS driver problem, but two other problems as well. Firstly, the GPU PCIe slot was one slot lower than normally, obstructing ventilation. Secondly, someone had stolen the WiFi/Bluetooth antenna from the sales box (it was a customer return item) and I hadn't realized that the antenna connector was proprietary.
I ended up buying a third motherboard: the ASRock Riptide B850M Phantom Gaming. After lots of tweaking and testing, I was able to get it stable under stress testing with a memory clock of 6200 MHz and good latencies.
I sometimes had trouble with the MediaTek MT7925 Bluetooth module, which would stop working, and it seems I'm not the only one. A full power-cycle resolved the issue eventually.
However, the worst part was that sometimes the computer just refused to POST, and sometimes it refused to shut down, instead just spinning the fans at 100%. I had the motherboard in use for a year and a half, and these symptoms became increasingly common. Until one day, the computer wouldn't boot at all. Turns out that ASRock motherboards are killing Ryzen CPUs. My 9900X was dead.
I ended up buying an Asus TUF GAMING B850M-PLUS II with a separate WiFi card with standard antenna connectors, and a new Ryzen 9 9950X CPU. After almost two years of weird problems, I finally have a stable AM5 computer that works as specified. The UAS USB driver also works. I also upgraded my GPU to an Asus TUF GAMING 9070 XT. It's been rock solid and extremely quiet.
Conclusion
When buying an AM5 system, choose your component brands carefully (Asus seems very solid) and don't expect anything to work out of the box. Check logs for errors carefully and test system stability with both y-cruncher and Prime95. And if you encounter weird stuff like fans suddenly spinning 100%, ditch your motherboard - your CPU might already be broken.
