Hacker News Reader

Comment by josephg | Hacker News Reader

Just for another datapoint: I'm using one of the new zen4 cpus with Linux Mint. I'm still using the older 5.15.0-50 kernel but almost everything is working fine anyway. That said:

- I'm using an old dedicated graphics card (a RX480) instead of the integrated graphics on the CPU.

- The system hard crashes when I suspend then resume.

- Wow is it slow to POST. It takes about 20 seconds from when I power it on before grub shows up. Hopefully this gets fixed in a future BIOS version. (MSI hasn't updated the BIOS since release.)

- I also get a few warnings in dmesg about ACPI objects being already defined.

Other than that, everything feels solid. Sound, wifi and ethernet all work fine. All the cores show up and run great.

View on HN

My zen3 system with 6800xt GPU doesn't resume from suspend reliably in Arch Linux. It works maybe 1 in 4 attempts. Otherwise, the AMDGPU driver hits a timeout and resets the GPU, and then my compositor has a bunch of open but invalid GL contexts or whatever. Sometimes I can switch to a virtual terminal and recover from it, but the attempt to do so tends to cause the system to lock up.

I have the same problem. Ryzen 5600H laptop. I "fixed" it with a posthook Script thats switches between my first and second tty. That works for me.

Interesting. Just switching to the tty doesn't fix things for me, though. I need to restart my whole graphical environment i.e. by restarting my display manager. So, it's about as convenient as just shutting down and powering back up.

It's unfortunate because my desktop eats up about 110W when idle, and approximately 0W when suspended. I also use some sketchy successor to "barrier" to share my mouse and keyboard with my work laptop, and that somehow keeps my monitors from shutting off if I happen to leave the mouse cursor on the laptop's screen. That's another 100W according to my UPS.

There are undoubtedly dozens of power plants that exist purely due to the overall number of software bugs that exist. They're talking about banning natural gas in favor of electrical heating here in California, and I live in a chillier climate, so I must be saving the Earth by leaving my desktop powered on most of the time out of convenience.

Same for me. I even had it working for a while but then a kernel upgrade or something else seemed to have broken it again.

It's frustrated me to the point that it was a major factor in deciding to splurge on buying a Steam Deck. The suspend / resume works so flawlessly on it that I weep. I keep an arbitrary game running on it in the drawer of my night stand. I don't actually have the energy to play a game that often, but knowing that resume button will work brings me great comfort.

> Just switching to the tty doesn't fix things for me

I found a very strange one... Had the same issue. Switching to tty and then back to GUI would work fine so, to me, it wasn't that much of an issue. I used that workaround for months. Then one day I decided to look into it: switched the HDMI cable for a DisplayPort cable and the problem is now gone! If I put the HDMI cable back on, the issue happens again. It may or may not help some people having similar issues with their desktops.

I currently have a monitor plugged in via DP, another one via HDMI, and a VR headset also via DP. Having the VR headset plugged in causes no shortage of display and audio bugs.

I need to change my desk configuration in a few months, and it's going to get a lot simpler since I am going to separate out my work setup. At that point I won't be able to justify keeping the desktop powered on 24/7, so working suspend would be a major quality of life improvement. I'll keep that in mind, and try to avoid HDMI completely.

This happens to me and I think it was a bug from a bios update to gigabyte motherboards. Haven't been able to suspend witbout a script for over a year.

I have a Gigabyte motherboard too, an Aorus Master b550. It was my first time going with their brand, and I'm ambivalent. The hardware seems nice. Their BIOS do seem a bit buggy, but I don't know how it compares to anything else this decade. I tried contacting their customer service to tell them their @bios tool doesn't work anymore, and it was a complete waste of my time.

On the other hand, why wouldn't this likely be an AMDGPU driver issue? I suppose I should try booting into Windows and suspending from there, just to see if it's reliable. I could also try backing off my fclk frequency, and disable resizeable BAR for the laughs. I could even go as far as swapping my older Nvidia GPU back in and see if that suspends and resumes ok. I'm expecting a new born baby this week, so it's not like I have anything better to do!

I don't like producing e-waste, but if I conclusively knew it was a systemic Gigabyte issue, I would seriously consider switching to a new motherboard from another vendor. I built this desktop after being in the hospital ICU for 5 days, and promised myself I wouldn't spare any expense. I also expect it to last the next decade, and so I don't want to be annoyed by it long term...

Would you be able to share the details of your script? Or does it simply switch to a virtual terminal before suspending, then switch back after resuming?

Man, you have a lot going on!

Regarding e-waste. Not sure where you live, but we have Freecycle and a Facebook "Buy nothing" group that my wife uses. They let us find a home for tons of stuff we otherwise would have had to throw out.

For posterity, I finally tracked down my suspend issue. It was a combination of an overly aggressive amdgpu.ppfeaturemask kernel option, and a regression in the kernel module. I updated archwiki so hopefully it doesn't bite anyone else.

I was inspired this morning to try, and switching to a virtual terminal before suspending seems to work in my case!

  [Unit]
  Description=Switches to a TTY before suspending
  Before=sleep.target
  StopWhenUnneeded=yes
  
  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/bin/bash -c 'fgconsole > 
  /tmp/fix_resume_active_console'
  ExecStart=/usr/bin/chvt 1
  ExecStop=/bin/bash -c '/usr/bin/chvt $(cat 
  /tmp/fix_resume_active_console)'
  
  [Install]
  WantedBy=sleep.target

> My zen3 system with 6800xt GPU doesn't resume from suspend reliably in Arch Linux.

My Zen3 system with a 6700XT suspends fine on PopOS

I finally just tracked down my issues. There was a recent addition to the amdgpu.ppfeaturemask kernel option, and the archwiki recommended value was enabling an unstable asynchronous mode. Additionally, there was a recent regression in the AMDGPU kernel module that's now fixed in 6.1rc2. So with a tweaked boot parameter and a manually compiled kernel, I have working suspend!

> Wow is it slow to POST

My understanding is that it is intentionally slow the first time you boot but should be normally slow after that. Apparently it is trying how fast it can clock the memory or something like that.

It is _ridiculously_ slow on first boot after a cleared CMOS due to the extra memory training - as in minutes. 20 seconds to post is the normal time after that initial boot and a decent time at that for these boards.

Any idea why they're so slow to post? Or if this is something that can ever be fixed? The b550 (zen 3) board I replaced was way faster.

I wouldn't mind so much if suspend & resume worked.

Suspend + resume works for me on Windows, haven’t tried Linux yet so can’t say if it’s in that half or maybe something board/firmware revision specific though.

Not sure why they take so much longer. Zen 3 was definitely faster for me as well. I’m not holding my breath that it’ll get significantly faster but I suppose it’s possible an update could do it.

> haven’t tried Linux yet so can’t say if it’s in that half or maybe something board/firmware revision specific though.

Its probably just bugs in the 5.15 kernel I'm still running. Full zen 4 support wasn't added until linux 6.0, so I think I'm doing well as it is. Fingers crossed suspend is fixed by a newer kernel.

Given everything else in the system seems to work fine, I'm not too fussed.

First-gen products often have issues like this. My old X370 board (zen1 era) turns off and on again twice before actually booting; a similar zen3 system doesn't need that and boots faster in general.

it's doing DDR Training. It's not necessarily how fast it can clock the memory. It's essentially putting an oscilloscope to the memory traces and checking how to generate the necessary signals fast enough while still being recognized on the other end. Simply because at the clock speeds and latency requirements of DDR5 Memory, the signal path is unique enough between CPUs, Motherboards and RAM Sticks that you need to configure the clock generation individually for that setup.

That makes sense for first boot. But does it really have to do some variant of that every time the system boots up?

How would it know if you haven't changed your RAM?

Consider that using the same settings with different parts might lead to subtle instability, not a full on-boot crash.

Surely it can know that. Don’t ram chips identify with vendor / serial number etc?

Serial numbers that are supposed to be unique aren't necessarily unique. I would guess that the BIOS talk to an EEPROM on the RAM modules rather than to the memory chips themselves. It would be very easy for a manufacturer to flash identical contents to every EEPROM in a batch, or with a sequentially increasing serial, rather than bother with a database.

What if you reinsert the same RAM stick into the same slot? Minute differences in insertion force and direction can lead to the frequency response of the RAM stick changing. Data paths might now be a micrometer long and require the BIOS to retrain the communication controller to compensate for that.

DDR5 tops out somewhere around 8 Gigahertz clock speed, which means the data signals travel 3 centimeters before the next clock signal arrives. At those time scales it means you're going to have to align those data signals down to the micrometer if you want them to be properly received.

That sounds awfully fragile to me. Any kind of bump to the case could cause problems?

It could. Probably not for most minor bumps but reinsertion in the slot is more likely to cause issues than small bumps once insertion forces are being applied constantly. Hence the BIOS has to check.

I don't have one of these systems, but my laptop does a quite slow training process on cleared CMOS or new memory, and it definitely doesn't do it every time. I would imagine they only rerun this kind of thing if the SPD doesn't match the one from the stored training, or something along those lines.

Why wouldn't it run a subset of tests on each boot? It seems like it would be silly not to. That's probably one of the mechanisms by which the bios will automatically revert to "safe" settings after a botched overclock.

You could do an experiment. Remove some of the RAM modules and see if the 20 second boot time decreases.

On some level, the BIOS has to determine if new chips have appeared on the bus. But also check that conditions haven't changed.

If you took out a RAM stick and inserted it into the same slot, the conditions (due to dust, moisture, difference in seating) could be enough to throw off the reliability of the training data. So at minimum it has to verify the settings to be correct.

I'm not sure if it needs to take that long, however --- from my understanding, the training process has existed in some form since the early days of DDR and it's done by a sort of binary search (set the timings to one end until errors start appearing, then to the other end, and choose the midpoint). Maybe the newer generations are doing far more worst-case testing?

Training becomes more complex as you approach higher frequency domains. It's not simply a trivial binary search anymore as there is more than a few parameters (how fast the clock has to rise, how long you can and must hold clock and data lines for, what order data lines have to be held in, to compensate for speed-of-light lag, etc.)

I found this[1] page helpful in describing the DD4 training and calibration procedure. Though, while it's fairly involved, I'd be surprised if it took minutes to complete.

[1]: https://www.systemverilog.io/ddr4-initialization-and-calibra...

>Wow is it slow to POST. It takes about 20 seconds from when I power it on before grub shows up

I remember from some reviews that the new Ryzens took a long time on the first boot for analyzing the RAM or something.

Could it be forgetting that analysis and having to do it again? Maybe try manually setting some RAM settings?

Out of curiosity what fabric and memory clock are you able to run at? I’m either extremely unlucky or running into an early firmware bug as I can’t get anything above 2100 MHz fabric to boot reliably.

I didn't touch the clock speeds from whatever the defaults are. Given the reported thermals, I'm tempted to go the other way and underclock the system. Losing ~5% performance to get a 50% reduction in power consumption would be a great deal if I can get it.

That said, I did activate EXPO on my 6000 MHz RAM sticks - which at first caused the system to hard freeze and nothing short of a CMOS clear could bring it back. But in the end, re-seating the RAM sticks seems to have sorted that one out and its running at the full rated speed now.

EXPO breaks S3 sleep at least in some cases. A few motherboard vendors even disable the S3 state when EXPO is enabled.

https://old.reddit.com/r/Amd/comments/xwfadm/when_expo_is_en...

I had the EXACT same problem. I left my machine running for 30 minutes after turning on EXPO after hearing about “training”.

Hard reboot, CPU code error… uh oh. Clear CMOS, boots again at 3000mhz. Decide to install Windows first, and then after I turned EXPO back on and have had zero issues at full rated speed. Even ram memtest to be sure.

Im running a MSI MPG x670e Carbon Wifi for what it’s worth.

Seems weird that installing windows fixed a ram issue. I wonder if there's a launch day CPU microcode update or something that windows installed that made a difference?

I'm also using a MSI board FWIW: MAG B650M Mortar (WIFI)

The German CT magazine tested the Ryzen 7000 recently and they said the eco mode (or similar name) reduced the power consumption significantly (IIRC <65W after) with only modest (<5%) performance drop.

IIRC they also said not to disable EXPO.

The 7950X at 65W TDP delivers 12% more than the 5950X at 105W TDP.

The 7700X at 65W TDP delivers 16% more than the 5800X at 105W TDP and 38% more than the 5700X at 65W TDP.

88W PPT = 65W TDP

And they can be undervolted as well.

Source: https://www.computerbase.de/2022-09/amd-ryzen-7950x-7900x-77...

edit: added 5700X

I’m running DDR5-6000 via EXPO and I haven’t had any issues with stability so far.

Now boot times on the other hand… If I didn’t have a motherboard with a debug digit readout, I definitely would have thought something was busted.

Hey josephg, does your motherboard disable sleep states when using XMP or EXPO memory configurations?

That could explain the crash when suspending.

How can you tell in Linux?

Reply on news.ycombinator.com