Hacker News Reader

Comment by sgtnoodle | Hacker News Reader

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.

View on HN

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.

> 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.

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.

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!

Reply on news.ycombinator.com