You are not logged in.
I simply forced DRI 2 instead of DRI 3, which seems to be buggy with Raven Ridge APUs and Xorg (Wayland worked fine). It also fixed some other small graphic related problems that I used to have.
Simply paste this into your xorg config:
Section "Device" Identifier "AMDGPU" Driver "amdgpu" Option "DRI" "2" EndSection
Wow, I think you got it. This is working flawlessly for me. We've all been looking at kernel patches and cmdline flags, but the fix was right there all along.
Offline
Running 5.4.0-arch1-1 with same old suspend issues.
Offline
Hello,
I've had the exact same problem on my Thinkpad A485 (AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx) and found a solution which allows me to run X, the latest stock kernels and suspending works like a charm.
I simply forced DRI 2 instead of DRI 3, which seems to be buggy with Raven Ridge APUs and Xorg (Wayland worked fine). It also fixed some other small graphic related problems that I used to have.
Simply paste this into your xorg config:
Section "Device" Identifier "AMDGPU" Driver "amdgpu" Option "DRI" "2" EndSectionMy command line flags are these, but some of them might not be needed anymore:
idle=nomwait amd_iommu=fullflush amdgpu.gpu_recovery=1Hope this helps someone!
I can't do this as I play Dota 2 using vulkan and vulkan requires dri 3 to be set in xorg
Last edited by sinatosk (2019-12-01 07:48:53)
Offline
On my t495s running the latest kernel 5.4.0-arch1-1 i can now succesfully hibernate. The problem arises on resume now, post boot i can see the screen flashing once and then go to black. I cannot even switch to another tty so the gpu is not properly started i guess.
I have enabled early kms and now i can also succesfully resume fine from hibernate. I should add that with the last previous known working kernel with hibernate i could do it without early kms.
Last edited by dimischiavone (2019-12-03 09:52:32)
Offline
On my t495s running the latest kernel 5.4.0-arch1-1 i can now succesfully hibernate. The problem arises on resume now, post boot i can see the screen flashing once and then go to black. I cannot even switch to another tty so the gpu is not properly started i guess.
I have enabled early kms and now i can also succesfully resume fine from hibernate. I should add that with the last previous known working kernel with hibernate i could do it without early kms.
Do you use any particular kernel parameters related to amd and/or iommu, etc..?
Offline
Do you use any particular kernel parameters related to amd and/or iommu, etc..?
No, i don't use any particular kernel command line to get it working.
Offline
No, i don't use any particular kernel command line to get it working.
Ok, I'm trying the same configuration on my t495. I tried to suspend/resume a couple of times and it seems to fail almost consistently after the 3rd time. Which is the same result I got from thousands of other configurations I tried haha.
As for hibernation, it worked once but I didn't have the time to try more times so I can't say if it consistently works with your config, although I doubt it; I'll confirm that later.
Offline
Ok, I'm trying the same configuration on my t495. I tried to suspend/resume a couple of times and it seems to fail almost consistently after the 3rd time. Which is the same result I got from thousands of other configurations I tried haha.
As for hibernation, it worked once but I didn't have the time to try more times so I can't say if it consistently works with your config, although I doubt it; I'll confirm that later.
Sound strange that you can't even suspend/resume properly.I don't think our devices differ that much either. I chose this laptop because i heard that thinkpads (especially the ones with amd cpus/gpus) worked really well with linux. In fact the first time i installed arch on this machine i was quite amazed that everything worked out of the box (some kernels ago suspend/hibernated worked fine too). As a note i should add that i run kde + sddm and i could also get secureboot + tpm2 to work without any issues on this thinkpad.
For me suspending always worked on this laptop, i had issues only with hibernation that seem to be fixed for the time being.
Edit:
I just remembered that sometimes when resuming from suspension the screen went all black and i couldn't even switch ttys. In those cases i just closed the screen again to put it back to sleep, tried again and it worked. Looks like sometimes the gpu isn't properly initialized.
Last edited by dimischiavone (2019-12-03 16:10:14)
Offline
Sound strange that you can't even suspend/resume properly.I don't think our devices differ that much either. I chose this laptop because i heard that thinkpads (especially the ones with amd cpus/gpus) worked really well with linux. In fact the first time i installed arch on this machine i was quite amazed that everything worked out of the box (some kernels ago suspend/hibernated worked fine too). As a note i should add that i run kde + sddm and i could also get secureboot + tpm2 to work without any issues on this thinkpad.
For me suspending always worked on this laptop, i had issues only with hibernation that seem to be fixed for the time being.
And that's exactly also why I bought a thinkpad haha! The device in itself is really amazing but the thing is, it's still pretty new. I learned the hard way that for new hardware like this, it does take some time for the kernel and other things to catch up. For example: the fingerprint reader isn't supported yet (well, this is changing since synaptics finally released firmware update, which are still in testing, on fwupd. also, see https://gitlab.freedesktop.org/libfprin … issues/181).
My point is, for the moment we're experiencing some compatibility issues due to the recentness of the device but that will progressively get fixed in the following months/weeks and future buyers will find this device to be perfectly compatible with our beloved OS, as most of the thinkpad are (I think?).
Edit:
I just remembered that sometimes when resuming from suspension the screen went all black and i couldn't even switch ttys. In those cases i just closed the screen again to put it back to sleep, tried again and it worked. Looks like sometimes the gpu isn't properly initialized.
Back to the hibernation/suspend problem: I still have this exact behavior your describing except I haven't been able to recover from it without a reboot unlike you. But it does seem that hibernation is working pretty good with the early KMS enabled! I didn't have a problem with it since the other day. Can't really say it works 100% of the time since I didn't use the hibernation a lot but I think this is almost solved.
Last edited by noom (2019-12-05 13:38:09)
Offline
Back to the hibernation/suspend problem: I still have this exact behavior your describing except I haven't been able to recover from it without a reboot unlike you. But it does seem that hibernation is working pretty good with the early KMS enabled! I didn't have a problem with it since the other day. Can't really say it works 100% of the time since I didn't use the hibernation a lot but I think this is almost solved.
Yeah but early kms is still a workaround that shouldn't be needed. I have tried the kernel mentioned earlier on this thread and with that all worked flawlessly without any particular kernel command line or kms. Like you mentioned i guess that's to blame to the fact that these devices are pretty new. Like you said, i'm sure that time will bring improvements and stability. Nonetheless it's amazing how almost all the hardware worked out of the box since day 1 (by the way i didn't get the fingerprint reader or the wwan due to the fact that for the former in the past no driver was released and for the latter because i would have had to change the wwan card myself).
For the time being i'm pretty happy that things work, even if with workarounds. Also i have tested the new kde power option "suspend then hibernate" and it also works flawlessly.
Last edited by dimischiavone (2019-12-05 18:05:45)
Offline
Yeah but early kms is still a workaround that shouldn't be needed. I have tried the kernel mentioned earlier on this thread and with that all worked flawlessly without any particular kernel command line or kms.
Are you referring to `5.4.1-arch1-1`?
Nonetheless it's amazing how almost all the hardware worked out of the box since day 1 (by the way i didn't get the fingerprint reader or the wwan due to the fact that for the former in the past no driver was released and for the latter because i would have had to change the wwan card myself).
Well I can't really compare since I always had old/used laptop before that already worked completely out of box (except for the IdeaPad 100S-11IBY which was absolute trash). But yeah I'm really enjoying this little beast even with these tiny issues that'll soon disappear!
For the time being i'm pretty happy that things work, even if with workarounds. Also i have tested the new kde power option "suspend then hibernate" and it also works flawlessly.
I haven't heard about this power mode, it looks really interesting, thanks for mentioning it!
Offline
I haven't heard about this power mode, it looks really interesting, thanks for mentioning it!
You could actually use it even before by editing systemd files related to sleep and hibernate but recently powerdevil has been integrated with this functionality too. When you suspend, after some time being idle suspended the computer will be hibernated.
I find it good for when you go to bed or when you have to suddenly go away from your computer. (I'm a big fan of always resuming my work from where i left without ever shutting down the computer).
Offline
Hi. I'm have black screen when type "systemctl suspend".
Method with Xorg:
Section "Device"
Identifier "AMDGPU"
Driver "amdgpu"
Option "DRI" "2"
EndSectionThis work unstable.
---------------------------------------
Arch Linux x86_64
5.4.2-arch1-1
WM: i3
CPU: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx (8) @ 2.100GHz
GPU: AMD ATI 04:00.0 Picasso
Offline
Since being on Kernel 5.4 ( 5.4.0 - 5.4.3 at this time of post )... it's quite rare for me to suspend successfuly
After every boot I can suspend 1-2 ( sometimes it never suspends after boot ) times before it fails to suspend for me and I'm not seeing any errors or warnings during this time... I have to cold reboot at this
When it does suspend, it never fails to wake from suspension
Hibernation works but waking up from hibernation I see just so many mixed errors and Xorg crashes so I have to start it again and continuing to hibnerating and wake from hibernate gives me more errors which eventually leads to unstable system so I have to cold reboot, The errors from hibernation seem random sometimes.
I've updated to the latest BIOS ( HP website ) and firmwares ( provided by linux-firmware package )
Offline
My A275 has also issues now suspending, but I do not know since when it happened. I remember with 5.4.1 it was just fine.
Offline
ok... maybe I'm talking too soon
this
sudo sh -c 'echo 0 > /sys/power/pm_async'disables asynchronous suspend and resume of devices, and after doing this, suspension is now working fine for me so far
I use custom kernel config that's based on arch linux kernel config. Arch linux recently enabled 'CONFIG_INIT_ON_ALLOC_DEFAULT_ON', I also enabled 'CONFIG_INIT_ON_FREE_DEFAULT_ON' and this caused issues with hibernation which eventually lead to seeing errors in dmesg that were literally saying "BUG" so I think it's a bug with linux and this platform when both enabled ( this was happening with '/sys/power/pm_async' set to '1' or '0' ). I've disabled 'CONFIG_INIT_ON_FREE_DEFAULT_ON' in my kernel config and now hibernation works fine
conclusion so far?
I think there some order dependency issue during suspension/hibernation with "/sys/power/pm_async" set to '1' which is the hardcoded default in the linux kernel source code file 'kernel/power/main.c', variable 'pm_async_enabled' and from what I've seen so far there is no kernel parameter to disable this
I also think there is a bug somewhere in linux and this platform related to hibernation when both 'CONFIG_INIT_ON_ALLOC_DEFAULT_ON' and 'CONFIG_INIT_ON_FREE_DEFAULT_ON' are enabled in the kernel config. I've not tried it with 'CONFIG_INIT_ON_FREE_DEFAULT_ON' enabled and 'CONFIG_INIT_ON_ALLOC_DEFAULT_ON' disabled
note: I've tested this both on custom kernel config and arch linux kernel config - version 5.4.3
Last edited by sinatosk (2019-12-16 09:35:07)
Offline
I have some error in dmesg
[ 0.816923] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.GPP2.BCM5], AE_NOT_FOUND (20190816/dswload2-159)
[ 0.816936] ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20190816/psobject-220)[ 1.401188] pci 0000:00:00.2: AMD-Vi: Unable to write to IOMMU perf counter.
[ 1.401319] pci 0000:00:00.2: can't derive routing for PCI INT A
[ 1.401320] pci 0000:00:00.2: PCI INT A: not connectedOffline
There are some queued patches for 5.4.6 for amd/amdgpu. one or two of the patches mentions something about semaphore/deadlock issues. Maybe they fix them although I'm under the impression they're still trying to track the problem as the title of one of the patches says 'workaround' and reading one of the patches it mentions something about semaphore firmware bug and a bunch of TODO's
but still yeah with file '/sys/power/pm_async' set to '0' has since allowed me to suspend and resume
with 'CONFIG_INIT_ON_FREE_DEFAULT_ON' disabled in kernel config or kernel parameter 'init_on_free' set to '0' or not set has since allowed me to hibernate and resume
another thing... setting kernel parameter 'xhci_hcd.quirks' to '1074143232' has got rid of the errors related to the 'USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1' pci device at pci address 04:00.4 ( I've noticed other show at 04:00.4 and 05:00.4 ) which I've noticed other people have shown during their warm/cold boot, reboot, suspension and hibernation
The 4 flags I've set on 'xhci_hcd.quirks' are
XHCI_SPURIOUS_REBOOT - BIT 13 (8192)
XHCI_SLOW_SUSPEND - BIT 17 (131072)
XHCI_SPURIOUS_WAKEUP - BIT 18 (262144)
XHCI_SUSPEND_DELAY - BIT 30(1073741824)
8192 + 131072 + 262144 + 1073741824 = 1074143232
I'm currently on kernel 5.4.5
Last edited by sinatosk (2019-12-21 08:12:58)
Offline
I am on 5.4.10-arch1-1 and I can neither suspend nor hibernate. I have the same issue of a black screen that is backlit and nothing else when trying to resume. No listed fixes have worked for me, and I'm on a t495
Offline
I'm on 5.4.10 both official and custom kernel
my kernel parameters are
add_efi_memmap root=/dev/sdvw rootfstype=filesystem_type rootflags=mount_options rw rootwait resume=/dev/sdxy resumewait hibernate=nocompress elevator=mq-deadline nmi_watchdog=0 acpi_backlight=vendor no_console_suspend amdgpu.gpu_recovery=1 xhci_hcd.quirks=1074143232the laptop I have is 'HP Pavilion Laptop 15-cw1507sa' 'UK region' which has an 'AMD Ryzen 5 3500U' with the bios/firmware updated to ( as of 10/01/2019 ) latest 'F.35 Rev.A'
I also have the file '/sys/power/pm_async' set to '0'
Using xorg-server 1.20.6-3
Using linux-firmware 20191220.6871bff-1 ( and later manually updated to 20200107.67d4ff5-1. This is unofficial, I just downloaded arch linux linux-firmware package and modified some values in the PKGBUILD file )
Using lib32-mesa-git and mesa-git 20.0.0_devel.118984.4e3a09db25c-1
since using kernel 5.4.3, 5.4.4, 5.4.5, 5.4.6, 5.4.7, 5.4.8 and 5.4.10, me doing what I said here, suspension & resume, hibernation & resume have succeeded with me everytime without warnings, errors, blank screen's, crashes and this is both before and after starting xorg.
It's unfournate that some still have these suspension/hibernation issues.
-- partially offtopic --
There are some other issues with this laptop that are most likely driver and/or firmware bugs/incompletion
- dual monitor enable mirroring which eventually cause a hard crash when running DOTA 2 but if I run DOTA 2 with dual monitor not mirroing ( tried this on multiple display panels ), then there is no crash
- kernel logs show the driver 'snd_pci_acp3x' at pci address '0000:04:00.5' keeps saying 'Invalid ACP audio mode : 1', but after some digging in the code it looks like AMD hasn't even implemented an audio mode for this device ( or it could be a bug... ) just like they recently just implemented the asic gpu reset for picasso in kernel 5.4 but prior to that, they didn't and people couldn't hibernate properly
- sound crackling issues, gets worst as the cpu usage is higher and even worst when using pulseeffects
- audio sounds gappy and crackly ( with or without pulseeffects enabled ) through hdmi and that too eventually leads to a hard crash
If AMD wants to be taken more seriously, they really need to up it on their drivers. I've noticed recently some people have been upset on the subreddit AMD about long ongoing driver issues for Windows. If I have hardware but unable to use it properly or at all due to buggy/incomplete/no drivers and/or firmware, I'm just gonna start looking at alternatives. I have some friends who still use Intel and Nvidia because they say their drivers are more reliable and that was actually why I was with Nvidia on the GPU side because ATI and then later AMD has bad drivers. AMD drivers on Linux have improved alot in the last 5~ years but still some issues that are ongoing.
Last edited by sinatosk (2020-01-10 17:15:59)
Offline
I'm on 5.4.10 both official and custom kernel
my kernel parameters are
add_efi_memmap root=/dev/sdvw rootfstype=filesystem_type rootflags=mount_options rw rootwait resume=/dev/sdxy resumewait hibernate=nocompress elevator=mq-deadline nmi_watchdog=0 acpi_backlight=vendor no_console_suspend amdgpu.gpu_recovery=1 xhci_hcd.quirks=1074143232the laptop I have is 'HP Pavilion Laptop 15-cw1507sa' 'UK region' which has an 'AMD Ryzen 5 3500U' with the bios/firmware updated to ( as of 10/01/2019 ) latest 'F.35 Rev.A'
I also have the file '/sys/power/pm_async' set to '0'
Using xorg-server 1.20.6-3
Using linux-firmware 20191220.6871bff-1 ( and later manually updated to 20200107.67d4ff5-1. This is unofficial, I just downloaded arch linux linux-firmware package and modified some values in the PKGBUILD file )
Using lib32-mesa-git and mesa-git 20.0.0_devel.118984.4e3a09db25c-1
since using kernel 5.4.3, 5.4.4, 5.4.5, 5.4.6, 5.4.7, 5.4.8 and 5.4.10, me doing what I said here, suspension & resume, hibernation & resume have succeeded with me everytime without warnings, errors, blank screen's, crashes and this is both before and after starting xorg.
It's unfournate that some still have these suspension/hibernation issues.
-- partially offtopic --
There are some other issues with this laptop that are most likely driver and/or firmware bugs/incompletion
- dual monitor enable mirroring which eventually cause a hard crash when running DOTA 2 but if I run DOTA 2 with dual monitor not mirroing ( tried this on multiple display panels ), then there is no crash
- kernel logs show the driver 'snd_pci_acp3x' at pci address '0000:04:00.5' keeps saying 'Invalid ACP audio mode : 1', but after some digging in the code it looks like AMD hasn't even implemented an audio mode for this device ( or it could be a bug... ) just like they recently just implemented the asic gpu reset for picasso in kernel 5.4 but prior to that, they didn't and people couldn't hibernate properly
- sound crackling issues, gets worst as the cpu usage is higher and even worst when using pulseeffects
- audio sounds gappy and crackly ( with or without pulseeffects enabled ) through hdmi and that too eventually leads to a hard crashIf AMD wants to be taken more seriously, they really need to up it on their drivers. I've noticed recently some people have been upset on the subreddit AMD about long ongoing driver issues for Windows. If I have hardware but unable to use it properly or at all due to buggy/incomplete/no drivers and/or firmware, I'm just gonna start looking at alternatives. I have some friends who still use Intel and Nvidia because they say their drivers are more reliable and that was actually why I was with Nvidia on the GPU side because ATI and then later AMD has bad drivers. AMD drivers on Linux have improved alot in the last 5~ years but still some issues that are ongoing.
So I removed my extra kernel parameters, re-built grub.cfg, re-added
no_console_suspend amdgpu.gpu_recovery=1 init_on_free=0and then re-built grub.cfg. After doing this, rebooted, and now resume and hibernate work.
Offline
kernel 5.5.0 is here ( in testing on arch linux )
after looking here, it seems they fixed the "init_on_free=1" issue.
judging by the patch it looks like it can be backported easily
I've compiled, installed and now running with hibernation working correctly with "init_on_free=1" set on kernel parameters.
All the other parameters, configurations I've done remain the same.
----------
Since 5.5.0 theres an error showing
[drm:dm_helpers_parse_edid_caps [amdgpu]] *ERROR* Couldn't read SADs: -2
----------
There was some sound crackling/gappy audio issues I mentioned earlier and phoronix has an article about AMD working on raven ridge apu audio clicky issues
Not mainled yet but heres a patch that fix some or all of these issues. I've not tried this yet as there is code in this patch that I can't see in 5.5 or lower. It looks like their some code refactoring going on here
Last edited by sinatosk (2020-01-29 12:09:43)
Offline
Hello,
T495 user here, kernel 5.4.15. Had to enable early KMS for the module amdgpu, to avoid xorg crashes starting a graphical session (using xinit). While hibernation works without any issue, resume from suspend doesn't, unless I manually switch to a tty session before suspend. Currently I'm okay with that workaround, not using any additional kernel parameter.
Offline
Try this solution: https://github.com/Pergravis?tab=projects
Offline
Hello,
T495 user here, kernel 5.4.15. Had to enable early KMS for the module amdgpu, to avoid xorg crashes starting a graphical session (using xinit). While hibernation works without any issue, resume from suspend doesn't, unless I manually switch to a tty session before suspend. Currently I'm okay with that workaround, not using any additional kernel parameter.
Yeah I forgot to mention that in my previous posts.
I too had to add the "amdgpu" module in the "mkinitcpio.conf" because of xorg crashes from using "startx"
Last edited by sinatosk (2020-02-01 17:37:49)
Offline