You are not logged in.
The latest linux-amd-staging-drm-next-git fixed the power consumption and the choppy DE
Can confirm, same here.
Offline
I'm intermittently (say, once every 30 minutes to a few hours) getting GPU freezes with the following output in dmesg:
[ 1672.031517] amdgpu 0000:0a:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:3 pasid:32773, for process SC2_x64.exe pid 3613 thread SC2_x64.ex:cs0 pid 3750)
[ 1672.031522] amdgpu 0000:0a:00.0: in page starting at address 0x000093800928f000 from client 27
[ 1672.031525] amdgpu 0000:0a:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00301030
[ 1672.031527] amdgpu 0000:0a:00.0: MORE_FAULTS: 0x0
[ 1672.031529] amdgpu 0000:0a:00.0: WALKER_ERROR: 0x0
[ 1672.031530] amdgpu 0000:0a:00.0: PERMISSION_FAULTS: 0x3
[ 1672.031532] amdgpu 0000:0a:00.0: MAPPING_ERROR: 0x0
[ 1672.031534] amdgpu 0000:0a:00.0: RW: 0x0
[ 1677.132305] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
[ 1682.038965] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=607212, emitted seq=607214
[ 1682.039040] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process SC2_x64.exe pid 3613 thread SC2_x64.ex:cs0 pid 3750
[ 1682.039042] [drm] GPU recovery disabled.
when running Starcraft II in Wine (wine-nine). I am using the linux-amd-staging-drm-next-git with latest agd5f firmware and mesa-git from lordheavy. Any ideas?
Offline
I've seen the same hang in WoW.
Offline
mesa-git from lordheavy
Where did you get that?
Offline
https://wiki.archlinux.org/index.php/Un … s#mesa-git
It's build against testing / multilib-testing repos and useful for people who prefer binaries.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
https://wiki.archlinux.org/index.php/Un … s#mesa-git
It's build against testing / multilib-testing repos and useful for people who prefer binaries.
Oh, then I already use that. I imagined lordheavy's was another repo. Since the link in the wiki says ~lcarlier I implied that was the name of the repo maintainer.
Offline
The latest linux-amd-staging-drm-next-git fixed the power consumption and the choppy DE
Sadly can't confirm regarding power consumption. It's even worse. I'm getting the error
[ 4061.756627] BUG: using __this_cpu_add() in preemptible [00000000] code: systemd-journal/553
[ 4061.756667] caller is down_read_trylock+0x15/0x50
[ 4061.756668] CPU: 19 PID: 553 Comm: systemd-journal Tainted: G W OE 5.2.0-rc1-amd-staging-drm-next-git-g865b4ca43816 #1
[ 4061.756669] Hardware name: System manufacturer System Product Name/ROG STRIX X570-E GAMING, BIOS 1005 08/01/2019
[ 4061.756669] Call Trace:
[ 4061.756670] dump_stack+0x5c/0x80
[ 4061.756672] __this_cpu_preempt_check+0xd4/0xe0
[ 4061.756674] down_read_trylock+0x15/0x50
[ 4061.756675] __do_page_fault+0x173/0x4d0
[ 4061.756677] do_page_fault+0x33/0x130
[ 4061.756679] ? page_fault+0x8/0x30
[ 4061.756680] page_fault+0x1e/0x30
[ 4061.756681] RIP: 0033:0x7fdea7e68d90
[ 4061.756682] Code: 76 08 48 83 80 e8 00 00 00 01 48 8b 44 24 18 48 8b 4c 24 08 48 83 c0 01 48 89 01 31 c0 e9 16 ff ff ff 0f 1f 84 00 00 00 00 00 <4d> 89 74 df 18 eb d9 66 0f 1f 84 00 00 00 00 00 4c 8d 05 d9 84 12
[ 4061.756683] RSP: 002b:00007ffd15235740 EFLAGS: 00010297
[ 4061.756684] RAX: 00000000000018ae RBX: 0000000000000520 RCX: 0000000000000006
[ 4061.756684] RDX: 0000000000000006 RSI: 00007fdea7f9099c RDI: 00007fde979345f8
[ 4061.756685] RBP: 000055571edaaed0 R08: 000000000000c588 R09: 000055571ed92540
[ 4061.756686] R10: 00007fde9b11a580 R11: 00000000001b5da6 R12: 0000000001f885f8
[ 4061.756686] R13: 00007ffd15235768 R14: 00000000033a5bd0 R15: 00007fde979345f8
every few seconds for different processes. Using "drm-next-5.4-2019-08-30" tag from https://cgit.freedesktop.org/~agd5f/linux/ everything works fine but still the power consumption issue.
A user at https://bugs.freedesktop.org/show_bug.cgi?id=111482#c6 reported that setting the refresh frequency for the monitor to 60 Hz solved the power consumption problem for him. But this doesn't work for me either. I've a resolution of 5144x1440 and my monitor can't get higher then 60 Hz in general. But maybe it fixes the issue for someone else if he has this issue.
Offline
I imagined lordheavy's was another repo. Since the link in the wiki says ~lcarlier I implied that was the name of the repo maintainer.
Lordheavy is the alias used by Laurent Carlier , see https://www.archlinux.org/people/developers/#lcarlier
I've a resolution of 5144x1440
Sounds like you are using a 49" 32:9 monitor ?
There's a big chance devs didn't test with that monitor type, maybe you could participate in the bug (if you already are participating, just ignore this line)
Is the screen connected through DP, HDMI, USB ?
Does using another cable type help ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
MadByteDE wrote:The latest linux-amd-staging-drm-next-git fixed the power consumption and the choppy DE
Can confirm, same here.
Are you using package from aur? When compiled kernel could not find modules even for hd. Did anyone have similar problem?
Offline
@ineedmana I had this problem yesterday. I'm using "yay" AUR helper. I somehow messed up with the Git repo while using different tags and branches during my tests. So I deleted ".cache/yay/linux-amd-staging-drm-next-git" directory and started from scratch. Also "/etc/mkinitcpio.d/linux-amd-staging-drm-next-git.preset" was completely different from what I expected. I had "linux-mainline.preset" around. So I copied that to "linux-amd-staging-drm-next-git.preset", adjusted it and also executed "mkinitcpio -P". Then everything was good again ;-)
Sounds like you are using a 49" 32:9 monitor? There's a big chance devs didn't test with that monitor type, maybe you could participate in the bug (if you already are participating, just ignore this line)
Yes, it is. I opened the bug https://bugs.freedesktop.org/show_bug.cgi?id=111482 around two weeks ago.
Is the screen connected through DP, HDMI, USB ? Does using another cable type help ?
I'm using DP. HDMI only gives you 3840x1080 which doesn't makes much sense. USB-C would be an option but the graphics card only has 3xDP and 1xHDMI.
But I figured out something else now and also updated the bug mentioned above: https://bugs.freedesktop.org/show_bug.cgi?id=111482#c15 . I just quote my bug comment here again:
Thanks Ilia for your comment! I get this output from "xrandr":
"""
Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-2 connected primary 5120x1440+0+0 (normal left inverted right x axis y axis) 1200mm x 340mm
5120x1440 60.00 + 30.00*+
3840x1080 60.00 +
3840x2160 60.00 30.00
1920x1200 60.00
1920x1080 60.00 59.94
1600x1200 60.00
1680x1050 60.00
1600x900 60.00
1280x1024 60.02
1440x900 60.00
1280x800 59.81
1152x864 59.97
1280x720 60.00 59.94
1024x768 60.00
800x600 60.32
720x480 60.00 59.94
640x480 60.00 59.94
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
"""So from what I can see only one monitor reported.
But I figured out something else: If I change the refresh rate from 60Hz to 30Hz I get 8W idle power consumption... Umpf... Now I've a big screen, kinda high end graphics card and 30Hz refresh rate It basically works but moving windows a little bit faster or moving the mouse pointer around looks "interesting". Haven't tested any games with that refresh rate but I guess it also looks "interesting" ;-)
What I don't get is why is 100Mhz memory clock speed for 5120x1440@30Hz is enough while the card stays at 875Mhz clock speed for 5120x1440@60Hz. I'm just an end user. I'm not that much into to the technical details. Maybe there is a technical reason for this.
Last edited by archixxx (2019-09-05 18:37:08)
Offline
Since I updated the bug report at https://bugs.freedesktop.org/show_bug.cgi?id=111482#c17 I thought I post the important information here too in case someone comes across with a similar problem.
So the best refresh rate with a resolution of 5120x1440 and 8W idle power consumption I could get was 39Hz using this commands ("xrandr" shows all your graphics card ports and I'm using DisplayPort-2 / "cvt12" utility was installed form AUR):
cvt12 5120 1440 39 -b
xrandr --output DisplayPort-2 --newmode "5120x1440_39.00_rb2" 297.51 5120 5128 5160 5200 1440 1453 1461 1467 +hsync -vsync
xrandr --output DisplayPort-2 --addmode DisplayPort-2 "5120x1440_39.00_rb2"
xrandr --output DisplayPort-2 --mode "5120x1440_39.00_rb2"
In my last comment I reported that "It basically works but moving windows a little bit faster or moving the mouse pointer around looks... interesting" if you use a resolution of 5120x1440@30Hz (this doesn't happen with 60Hz but then you have 34 idle power consumption). With "interesting" I basically meant kind of "flickering". So I saw horizontal lines across the screen a few times per minute and other screen "mysteries" ;-) You can live with it but it gets annoying after a while. But this issue I was able to work around :-) After I start KDE plasma I enter Konsole and run two commands:
echo "1" > /sys/class/drm/card0/device/pp_dpm_mclk
echo "0" > /sys/class/drm/card0/device/pp_dpm_mclk
The first command sets mem clock to 500Mhz and the second one sets it back to 100Mhz. And that's it! No strange flickering anymore.
One final observation: I tried out "aur/linux-mainline 5.3rc8-1". With that kernel there is no way to reduce idle power consumption. Even if you just stay in the Linux console and don't start any DE it stays at 34W regardless what you do (at least this was the case for me ;-) ). But with this tag https://cgit.freedesktop.org/~agd5f/lin … 2019-08-30 (which basically is kernel 5.3-rc3 with the Navi10 patches for kernel 5.4 - if I got it right ;-) ) idle power consumption is as expected. So next stop to try out in a few weeks: "aur/linux-mainline 5.4rc1"
But leaving this issues aside it's working quite ok now for me too.
Offline
Is there a succinct list somewhere of the minimum versions / commits we need in the various packages in order to get the 5700XT working?
Is it worth making a page on the wiki for this?
It'd make it easier to track when we can move back from git/AUR for certain packages
Offline
Is there a succinct list somewhere of the minimum versions / commits we need in the various packages in order to get the 5700XT working?
Is it worth making a page on the wiki for this?
It'd make it easier to track when we can move back from git/AUR for certain packages
A wiki page sounds like a good idea. Maybe call it Navi 10?
Offline
Also, LLVM 9.0 just went stable: https://lists.llvm.org/pipermail/llvm-a … 00085.html
Do we absolutely depend on LLVM 10?
Offline
Is there a succinct list somewhere of the minimum versions / commits we need in the various packages in order to get the 5700XT working?
Is it worth making a page on the wiki for this?
It'd make it easier to track when we can move back from git/AUR for certain packages
I just created the wiki page about Navi 10. You can find it here: https://wiki.archlinux.org/index.php/Navi_10
Feel free to add anything you see fit.
Offline
I just created the wiki page about Navi 10. You can find it here: https://wiki.archlinux.org/index.php/Navi_10
Thanks so much!
Offline
Okay, so, it looks like we should be fine with LLVM 9.0: https://releases.llvm.org/9.0.0/docs/Re … gpu-target
So, once that's in stable, we can update the other packages to depend upon it instead of llvm-git, etc
I'll update the wiki page
Offline
Hi guys,
since the 5.3 kernel is available in stable since today, the 5700 XT should now work when the correct kernel is installed, right? Is there good manual somewhere how to migrate from nvidia proprietary to the 5700 XT. I tried to do that and it turned out to be quite the catastrophe for me. All good due to snapshots though.
Offline
No, as mentioned in this thread and in the created wiki page, the kernel is just one component. There's no in repo package containing the firmware files yet.
Switching from nvidia should be as simple as uninstalling nvidia, nvidia-utils and lib32-nvidia-utils and any xorg configuration referencing nvidia if present.
Offline
Hello all!
Just wanted to say thanks for putting the wiki page together.
I also wanted to post a small update:
Please update the firmware which is provided by the package on arch it's quite out of date.
https://people.freedesktop.org/~agd5f/r … de/navi10/ -- This firmware solves any choppyness I had in KDE.
I manually wget'ed the up to date firmware and overwrote it all.
Additionally, the GPU package breaks compatibility with the R9 390X I have pulled this and put my RX 5700 XT so it's not a major problem but it should definitely be patched at some point.
Xorg fails to start with the R9 390X after installing the wiki recommended packages.
Offline
Please update the firmware which is provided by the package on arch it's quite out of date.
https://people.freedesktop.org/~agd5f/r … de/navi10/ -- This firmware solves any choppyness I had in KDE.
Do you mean the package linux-firmware-agd5f-radeon-navi10? It pulls the latest version available at build time.
You can rebuild the package to update the version.
Additionally, the GPU package breaks compatibility with the R9 390X I have pulled this and put my RX 5700 XT so it's not a major problem but it should definitely be patched at some point.
Xorg fails to start with the R9 390X after installing the wiki recommended packages.
Are you referring to the packages from the mesa-git repository?
Offline
RevoluPowered wrote:Please update the firmware which is provided by the package on arch it's quite out of date.
https://people.freedesktop.org/~agd5f/r … de/navi10/ -- This firmware solves any choppyness I had in KDE.Do you mean the package linux-firmware-agd5f-radeon-navi10? It pulls the latest version available at build time.
You can rebuild the package to update the version.RevoluPowered wrote:Additionally, the GPU package breaks compatibility with the R9 390X I have pulled this and put my RX 5700 XT so it's not a major problem but it should definitely be patched at some point.
Xorg fails to start with the R9 390X after installing the wiki recommended packages.
Are you referring to the packages from the mesa-git repository?
In relation to the firmware:
- linux-firmware-agd5f-radeon-navi10A
I found that after installing that and rebooting the DE was slow and choppy as others have reported, so after I manually put them in the same place as that package it worked, could this be a bug or it failing to overwrite existing firmware when making the AUR package?
To clarify the problem with the R9 390X xorg server launching was in the mesa radeon driver failing to initialize with the legacy hardware after the update.
Might be a regression, I will see how support improves over the next week or so and if nothing happens will file the bug with Mesa as a regression.
Last edited by RevoluPowered (2019-09-20 20:41:00)
Offline
Could someone please update the linux53 kernel package to the released version, right now linux53 is pointing to rc7 which is not the same as the linux-kernel 5.3 release version, rc8 was next then full release of 5.3.
https://git.kernel.org/pub/scm/linux/ke … s/?id=v5.3
May help with some stability issues.
Noticed in the commit history it has a bunch of NVME related fixes for those of us gaming may help with some of the jitters in vkdx. Also has kernel hang issues fixed too which was patched in 5.2 as well.
Last edited by RevoluPowered (2019-09-20 20:49:30)
Offline
What linux53 package do you mean? linux-mainline from the AUR is using the v5.3 tag, the official linux package in [core] is using v5.3 with two additional patches.
Edit: linux-amd-staging-drm-next-git will always use the most recent staging branch that amd is developing.
Edit: I believe linux53 exists in manjaro. You won't receive support for manjaro problems in this forum. These boards are for the support of Arch Linux, and Arch ONLY
Manjaro is known to delay package updates for some days/weeks in the name of stability.
Last edited by progandy (2019-09-20 21:34:39)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
In relation to the firmware:
- linux-firmware-agd5f-radeon-navi10AI found that after installing that and rebooting the DE was slow and choppy as others have reported, so after I manually put them in the same place as that package it worked, could this be a bug or it failing to overwrite existing firmware when making the AUR package?
I forgot if the sources listed in the PKGBUILD are already present locally you would need to delete them to trigger an update to a more recent version as they are not managed by a version control system.
Offline