|
Description
KostWarCZE
2018-10-03 23:35:38 UTC
Created attachment 549208 [details]
make.conf
Created attachment 549210 [details]
eix-installed -a
Created attachment 549212 [details]
emerge --info
Created attachment 549214 [details]
vulkaninfo from user
Created attachment 549216 [details]
vulkan info on root
Created attachment 549218 [details]
/etc/group
Added files as an attachment on request. Created attachment 549220 [details]
root # strace -o trace.log -f -s 1000000 vulkaninfo
Created attachment 549222 [details]
user $ strace -o trace.log -f -s 1000000 vulkaninfo
WARNING: POSSIBLE DUPLICATE
strace -o trace.log -f -s 1000000 vulkaninfo on user results in strace: Can't fopen 'trace.log': Permission denied.
It's possible that trace.log is duplicate of root # strace -o trace.log -f -s 1000000 vulkaninfo
Added `media-libs/mesa vulkan` to `/etc/portage/package.use/custom` in addition to other use flag. no effect on vulkaninfo.+ Downgraded vulkan-loader and mesa on stable from testing. Same issue Created attachment 549224 [details] /etc/default/grub Tried something that worked on debian, more info: https://askubuntu.com/questions/1041394/vk-error-incompatible-driver-error-with-vulkan-on-ati-sapphire-7870-running-xu/1042801#1042801 No effect on the issue. Sane configuration seems as GRUB_CMDLINE_LINUX="radeon.si_support=1 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=0", but this config was recommended by trusted(?) community member. Using config above results also in no effect on the issue. Changed on GRUB_CMDLINE_LINUX="radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1" since it seems sane to me. (In reply to KostWarCZE from comment #9) > Created attachment 549222 [details] > user $ strace -o trace.log -f -s 1000000 vulkaninfo > > WARNING: POSSIBLE DUPLICATE > > strace -o trace.log -f -s 1000000 vulkaninfo on user results in strace: > Can't fopen 'trace.log': Permission denied. > > It's possible that trace.log is duplicate of root # strace -o trace.log -f > -s 1000000 vulkaninfo You might try running strace from a directory your user can write to. ~/ is often a good choice, and /tmp a good secondary location. Created attachment 549232 [details]
strace -o trace.log -f -s 1000000 vulkaninfouser /tmp $
invoking `strace -o trace.log -f -s 1000000 vulkaninfo` from user in /home/$USER/ result in:
strace: Can't fopen 'trace.log': Permission denied
Invoking from /tmp seems to be working.
Do I understand it correct, that it works with other Kernel versions? (In reply to Jonas Stein from comment #15) > Do I understand it correct, that it works with other Kernel versions? Last time when i was on 4.14.X it worked iirc, but i didn't tried other versions atm. Can test other versions on demand. (In reply to Jonas Stein from comment #15) > Do I understand it correct, that it works with other Kernel versions? Can try other versions on demand. You can also contact me via #gentoo-support on Freenode, happy to provide more info. I would be very surprised if this were a packaging bug. I expect it is either a kernel bug, or an upstream implementation bug. Can you find try to find a kernel version where vulkan-info works? Thanks, Sarnex (In reply to Nick Sarnie from comment #18) > I would be very surprised if this were a packaging bug. I expect it is > either a kernel bug, or an upstream implementation bug. > > Can you find try to find a kernel version where vulkan-info works? > > Thanks, > Sarnex Trying other kernel versions list of tried solution is provided here: https://docs.google.com/document/d/10rzV0HKSMwXptIdPoZM6907PtrKFoQohsjKoBgjj4wY/edit Will update with results. Created attachment 549410 [details]
4.18.4-gentoo - USER vulkaninfo
4.18.4-gentoo - USER vulkaninfo
Created attachment 549412 [details]
4.18.4-gentoo - USER vulkaninfo in /tmp
4.18.4-gentoo - strace USER vulkaninfo invoked from /tmp.
Created attachment 549414 [details]
4.18.4-gentoo - strace ROOT vulkaninfo from /tmp.
4.18.4-gentoo - strace ROOT vulkaninfo invoked from /tmp.
Created attachment 549416 [details]
4.18.4-gentoo - ROOT vulkaninfo.
(In reply to Nick Sarnie from comment #18) > I would be very surprised if this were a packaging bug. I expect it is > either a kernel bug, or an upstream implementation bug. > > Can you find try to find a kernel version where vulkan-info works? > > Thanks, > Sarnex Based on my math it would take 8 hours and 21 minutes to try all kernel versions. Can you provide me a list of kernel versions you want me to test? Compiling 4.14.65 next since it's lastest stable in https://packages.gentoo.org/packages/sys-kernel/gentoo-sources. Note that "dev-util/vulkan-tools is not working on 4.18.9-gentoo" is not accurate since vulkan is NOT working in any vulkan application. Tested in wine (lutris for GTA V with DXVK) and DotA 2. Seems like a permissions issue. 5914 openat(AT_FDCWD, "/dev/dri/renderD128", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission denied) For me: openat(AT_FDCWD, "/dev/dri/renderD129", O_RDWR|O_CLOEXEC) = 3 Not sure how much I can help here. Can you try adding yourself to plugdev? Sarnex Created attachment 549418 [details]
4.14.65 - USER strace vulkaninfo in /tmp
Created attachment 549420 [details]
4.14.65 - USER vulkaninfo.
Created attachment 549422 [details]
4.14.65 - ROOT strace vulkaninfo in /tmp.
Created attachment 549424 [details]
4.14.65 - ROOT vulkaninfo.
(In reply to Nick Sarnie from comment #27) > Seems like a permissions issue. > > 5914 openat(AT_FDCWD, "/dev/dri/renderD128", O_RDWR|O_CLOEXEC) = -1 EACCES > (Permission denied) > > For me: > > openat(AT_FDCWD, "/dev/dri/renderD129", O_RDWR|O_CLOEXEC) = 3 > > Not sure how much I can help here. Can you try adding yourself to plugdev? > > Sarnex dreamon /tmp # usermod -a -G plugdev kreyren results in same issue on USER. (In reply to KostWarCZE from comment #32) > (In reply to Nick Sarnie from comment #27) > > Seems like a permissions issue. > > > > 5914 openat(AT_FDCWD, "/dev/dri/renderD128", O_RDWR|O_CLOEXEC) = -1 EACCES > > (Permission denied) > > > > For me: > > > > openat(AT_FDCWD, "/dev/dri/renderD129", O_RDWR|O_CLOEXEC) = 3 > > > > Not sure how much I can help here. Can you try adding yourself to plugdev? > > > > Sarnex > > dreamon /tmp # usermod -a -G plugdev kreyren > > results in same issue on USER. Have you rebooted after that change? Also, as we know exactly what call is causing the error, there is no need for any more attachments. What is the output of stat /dev/dri/renderD128 Thanks, Sarnex (In reply to Nick Sarnie from comment #33) > (In reply to KostWarCZE from comment #32) > > (In reply to Nick Sarnie from comment #27) > > > Seems like a permissions issue. > > > > > > 5914 openat(AT_FDCWD, "/dev/dri/renderD128", O_RDWR|O_CLOEXEC) = -1 EACCES > > > (Permission denied) > > > > > > For me: > > > > > > openat(AT_FDCWD, "/dev/dri/renderD129", O_RDWR|O_CLOEXEC) = 3 > > > > > > Not sure how much I can help here. Can you try adding yourself to plugdev? > > > > > > Sarnex > > > > dreamon /tmp # usermod -a -G plugdev kreyren > > > > results in same issue on USER. > > Have you rebooted after that change? > > Also, as we know exactly what call is causing the error, there is no need > for any more attachments. > > What is the output of stat /dev/dri/renderD128 > > > Thanks, > Sarnex Didn't reboot reboting now. stout of stat /dev/dri/renderD128 is: File: /dev/dri/renderD128 Size: 0 Blocks: 0 IO Block: 4096 character special file Device: 6h/6d Inode: 13419 Links: 1 Device type: e2,80 Access: (0600/crw-------) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-10-05 00:34:31.151999999 -0000 Modify: 2018-10-05 00:34:31.151999999 -0000 Change: 2018-10-05 00:34:31.151999999 -0000 Birth: - Note that this stout was taked BEFORE reboot. Here is my output: File: /dev/dri/renderD129 Size: 0 Blocks: 0 IO Block: 4096 Device: 6h/6d Inode: 22940 Links: 1 Device type: e2,81 Access: (0666/crw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-10-04 18:05:15.042000032 -0400 Modify: 2018-10-04 18:05:15.042000032 -0400 Change: 2018-10-04 18:08:37.989003304 -0400 Birth: - Clearly the permissions are different. I expect chmodding the node to 666 would fix your problem, but I don't know why that would change. Sarnex After reboot no effect on vulkaninfo and stat...
> chmodding the node to 666 would fix your problem
Please provide more info
(In reply to KostWarCZE from comment #36) > After reboot no effect on vulkaninfo and stat... > > > chmodding the node to 666 would fix your problem > > Please provide more info Try sudo chmod 666 /dev/dri/renderD128 Sarnex Created attachment 549426 [details]
4.14.65 - USER vulkan after chmod.
ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
WARNING: radv is not a conformant vulkan implementation, testing use only.
still present?
As expected, that fixed it. I'm not sure why permissions on that could change. (In reply to Nick Sarnie from comment #39) > As expected, that fixed it. I'm not sure why permissions on that could > change. But it seems that vulkan is still not working. Is there any reliable way to verify it? (Not sure if using vulkaninfo or DotA 2 is reliable) What makes you believe it is not working? Please try DOTA 2. Also, I'm not sure if your card is expected to work as it is older. Sarnex (In reply to Nick Sarnie from comment #41) > What makes you believe it is not working? Please try DOTA 2. Also, I'm not > sure if your card is expected to work as it is older. > > Sarnex Note that same hardware configuration worked on Debian with vulkan. Based on previous experience on debian i believe that mentioned error `ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_radeon.so: wrong ...` indicates problems with vulkan since i had very simmilar problem on debian. Based on provided info i believe that setting chmod just solved problems with using vulkaninfo from user since it now outputs same error as on root. Installing DotA 2 will test vulkan in +- 10 hours cause of my limited time atm. Relevant? https://askubuntu.com/questions/1041394/vk-error-incompatible-driver-error-with-vulkan-on-ati-sapphire-7870-running-xu (In reply to KostWarCZE from comment #42) > (In reply to Nick Sarnie from comment #41) > > What makes you believe it is not working? Please try DOTA 2. Also, I'm not > > sure if your card is expected to work as it is older. > > > > Sarnex > > Note that same hardware configuration worked on Debian with vulkan. > > Based on previous experience on debian i believe that mentioned error > `ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_radeon.so: wrong ...` > indicates problems with vulkan since i had very simmilar problem on debian. > > Based on provided info i believe that setting chmod just solved problems > with using vulkaninfo from user since it now outputs same error as on root. > > Installing DotA 2 will test vulkan in +- 10 hours cause of my limited time > atm. > > Relevant? > https://askubuntu.com/questions/1041394/vk-error-incompatible-driver-error- > with-vulkan-on-ati-sapphire-7870-running-xu The error is harmless, since you have 32-bit mesa there are two files for vulkan-loader to choose from. It's trying the 32-bit one first, erroring out because it's 32bit, and then trying the 64 bit one. I expect vulkan to work. Either way, this isn't a vulkan-tools issue so I'm closing the bug. Thanks, Sarnex Can confirm that vulkan is now working based on DotA2 with Vulkan DLC and `-vulkan` argument. Which was confirmed before opening bug too for 4.14.65-gentoo. Note that this bug report was opened by me for Vulkan on 4.18.9-gentoo NOT vulkan-tools!! Provided vulkan-tools based on previous experience on debian where it's used to debug vulkan. Will verify on 4.18.9-gentoo later, expecting it to fail again. Even if it fails on a newer kernel, the problem is in the permissions of the render node, which is not a problem with any of the vulkan-* packages. Thank you for your understanding. Sarnex (In reply to Nick Sarnie from comment #45) > Even if it fails on a newer kernel, the problem is in the permissions of the > render node, which is not a problem with any of the vulkan-* packages. > > Thank you for your understanding. > > Sarnex Disagree, i understand that invoking `sudo chmod 666 /dev/dri/renderD128` should set the correct permission for a render node, but Vulkan is NOT working on 4.18.9-gentoo again. New info: invoking `sudo chmod 666 /dev/dri/renderD128` on 4.18.9-gentoo (invoked before on 4.14.65) "seems to" solved the issue. Please confirm the bug for VULKAN, based on provided informations i strongly believe that this report is not relevant to vulkan-tools! New info: it's required to invoke `sudo chmod 666 /dev/dri/renderD128` on every reboot(?) since old permissions got re-set each time. (or so it seems) Hi, Yes, you will need to do it on every reboot. I agree that chmodding it is not a real fix. My guess is there is some system misconfiguration causing low permissions on the render node. Unfortunately, I cannot provide general Vulkan, X11, or system assistance. As this is not a bug with any vulkan-* packages, and Gentoo bugs in general track issues with specific packages, I am reclosing the bug. Feel free to reach out to the Gentoo or Linux community for assistance solving this issue. Sarnex confirm ~ $ vulkaninfo ========== VULKANINFO ========== Vulkan Instance Version: 1.1.77 /tmp/portage/dev-util/vulkan-tools-1.1.82.0/work/Vulkan-Tools-2cfddd146d666efe0ed06ef1d2bc5565821df144/vulkaninfo/vulkaninfo.c:3339: failed with VK_ERROR_INITIALIZATION_FAILED ~ $ sudo chmod 666 /dev/dri/renderD128 ~ $ vulkaninfo ========== VULKANINFO ========== Vulkan Instance Version: 1.1.77 INTEL-MESA: warning: Haswell Vulkan support is incomplete INTEL-MESA: warning: ../mesa-9999/src/intel/vulkan/anv_device.c:1173: FINISHME: Implement pop-free point clipping Hello,
I want to communicate again that this is bug should not be the place to report this issue, as it is not a packaging issue.
I spoke with imirkin who suggested this may be a udev rule or systemd issue.
The permissions of the render node are initially set by udev. Specifically, the render node rules are in /lib/udev/rules.d/{dev-default.rules,rm.rules,dev-acl.rules}. On my system I see the following lines:
udev-default.rules:SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video"
50-udev-default.rules:SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="0666"
50-udev-default.rules:SUBSYSTEM=="kfd", GROUP="render", MODE="0666"
I am using OpenRC, so my render node permissions end up as 0666.
First, I would check your local udev rules to see if they are confirmed the same.
You could also try adding yourself to and/or creating the render group.
If they are, and you are using systemd, then like systemd is somehow changing the permissions.
Either way, this is not a packaging bug so please refrain from using this bug for troubleshooting.
Thanks,
Sarnex
noted, needed info to confirm that it's not bug since i understand that it is based on info from #gentoo-*. Resolving vulkan on gentoo forum already, I have ~ $ cat /lib/udev/rules.d/50-udev-default.rules | grep -i drm SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="@GROUP_RENDER_MODE@" (In reply to Perfect Gentleman from comment #53) > I have > ~ $ cat /lib/udev/rules.d/50-udev-default.rules | grep -i drm > SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" > SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", > MODE="@GROUP_RENDER_MODE@" ~ $ cat /lib/udev/rules.d/50-udev-default.rules | grep -i kfd SUBSYSTEM=="kfd", GROUP="render", MODE="@GROUP_RENDER_MODE@" (In reply to Perfect Gentleman from comment #54) > (In reply to Perfect Gentleman from comment #53) > > I have > > ~ $ cat /lib/udev/rules.d/50-udev-default.rules | grep -i drm > > SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" > > SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", > > MODE="@GROUP_RENDER_MODE@" > > ~ $ cat /lib/udev/rules.d/50-udev-default.rules | grep -i kfd > SUBSYSTEM=="kfd", GROUP="render", MODE="@GROUP_RENDER_MODE@" That looks like a problem. % cat /lib/udev/rules.d/50-udev-default.rules | grep -i drm SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="0666" @GROUP_RENDER_MODE@ was supposed to be replaced. What eudev/udev/systemd are you using? I have sys-apps/systemd-238-r7 (In reply to Matt Turner from comment #55) > (In reply to Perfect Gentleman from comment #54) > > (In reply to Perfect Gentleman from comment #53) > > > I have > > > ~ $ cat /lib/udev/rules.d/50-udev-default.rules | grep -i drm > > > SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" > > > SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", > > > MODE="@GROUP_RENDER_MODE@" > > > > ~ $ cat /lib/udev/rules.d/50-udev-default.rules | grep -i kfd > > SUBSYSTEM=="kfd", GROUP="render", MODE="@GROUP_RENDER_MODE@" > > That looks like a problem. > > % cat /lib/udev/rules.d/50-udev-default.rules | grep -i drm > SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" > SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="0666" > > @GROUP_RENDER_MODE@ was supposed to be replaced. > > What eudev/udev/systemd are you using? I have sys-apps/systemd-238-r7 eudev & openrc Thanks, I'll reassign to eudev. Cc'ing x11@ just because I'm interested to see the conclusion. This is a regression in 3.2.6. It seems to have been fixed upstream. Removing x11@. Created attachment 551302 [details]
RADEON - strace -o trace.log -f -s 1000000 vulkanifo from ROOT.
Same issue on Radeon GPU while AMDGPU and RADEON is set as modular and compiled in kernel 4.18.9-gentoo.
`sudo chmod 666 /dev/dri/renderD128` is not working this time.
Sending strace.
Additional info: `/etc/default/grub` has `GRUB_CMDLINE_LINUX="radeon.si_support=1 amdgpu.si_support=0"` None on gentoo forum and IRC knows what is wrong with it: https://forums.gentoo.org/viewtopic-t-1087336.html only more users has the same issue. Created attachment 551304 [details]
2018-10-15 eix-installed -a
Adding also list of installed packages.
Requesting to confirm bug as a reaction on provided response from gentoo forum, IRC and that multiple users confirmed same issue.
There are no resources for gentoo users to fix this issue to my knowledge.
$ cat /lib/udev/rules.d/50-udev-default.rules | grep -i drm SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="@GROUP_RENDER_MODE@" if viewed from subl line 33-34 has > SUBSYSTEM=="graphics", GROUP="video" > SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" `, MODE="@GROUP_RENDER_MODE@"` is not present. line 39 has: SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="@GROUP_RENDER_MODE@" based on info from https://github.com/gentoo/eudev/commit/a8ffcd1b985fb4b3e2c3a1cb9051bed86f69d3f3 changing: line 39: --- SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="@GROUP_RENDER_MODE@" +++ SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="video", MODE="0666" line 40: --- SUBSYSTEM=="kfd", GROUP="render", MODE="@GROUP_RENDER_MODE@" +++ SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="video", MODE="0666" line 82: --- KERNEL=="kvm", GROUP="kvm", MODE="@DEV_KVM_MODE@", OPTIONS+="static_node=kvm" +++ KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm" (In reply to KostWarCZE from comment #62) > $ cat /lib/udev/rules.d/50-udev-default.rules | grep -i drm > SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" > SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", > MODE="@GROUP_RENDER_MODE@" > > if viewed from subl line 33-34 has > > SUBSYSTEM=="graphics", GROUP="video" > > SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" > > `, MODE="@GROUP_RENDER_MODE@"` is not present. > > line 39 has: > SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", > MODE="@GROUP_RENDER_MODE@" > > based on info from > https://github.com/gentoo/eudev/commit/ > a8ffcd1b985fb4b3e2c3a1cb9051bed86f69d3f3 > > changing: > line 39: > --- SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", > MODE="@GROUP_RENDER_MODE@" > +++ SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="video", MODE="0666" > line 40: > --- SUBSYSTEM=="kfd", GROUP="render", MODE="@GROUP_RENDER_MODE@" > +++ SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="video", MODE="0666" > line 82: > --- KERNEL=="kvm", GROUP="kvm", MODE="@DEV_KVM_MODE@", > OPTIONS+="static_node=kvm" > +++ KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm" Had no effect, revert changes. trying 9999 version of sys-fs/eudev. rebooted and sys-fs/eudev-9999 does NOT have effect on broken vulkan on ATI drivers. Note that i allowed AMDGPU in /etc/default/grub. (In reply to KostWarCZE from comment #64) > rebooted and sys-fs/eudev-9999 does NOT have effect on broken vulkan on ATI > drivers. > > Note that i allowed AMDGPU in /etc/default/grub. confirm that there are no effects changing to high-critical.. 1) vulkan is not working on AMDGPU nor RADEON even with HOTFIX atm. 2) none seem to care 3) multiple users are affected 4) grknight is providing missleading info on wiki about this issue. CONFIRM IT ALREADY! switching on udev fixed the issue for AMDGPU. If radeon is compiled in the kernel as modular with AMDGPU for SI and set in /etc/default/grub for radeon or AMDGPU (depending on the /etc/default/grub) is not working. If radeon is out-compiled from the kernel and AMDGPU is used with udev the vulkan is working. Suspect issues with radeon kernel config. (In reply to KostWarCZE from comment #63) > Had no effect, revert changes. > > trying 9999 version of sys-fs/eudev. This is not a bug in eudev as far as I can see. Also, both the severity and priority are normal. Please do not change them. I cannot confirm the bug because I cannot reproduce it. (In reply to Anthony Basile from comment #68) > (In reply to KostWarCZE from comment #63) > > > Had no effect, revert changes. > > > > trying 9999 version of sys-fs/eudev. > > > This is not a bug in eudev as far as I can see. Also, both the severity and > priority are normal. Please do not change them. > > I cannot confirm the bug because I cannot reproduce it. STEPS TO REPRODUCE: a) overkill 1) Get a AMD GPU. 2) Make a new partition of the size around 5-50GB to fit the installation. 3) Emerge gentoo with `~amd64`, Desktop profile and kernel configuration for AMDGPU as modular for CIK/SI. 4) emerge `vulkaninfo` on it. 5) invoke `vulkaninfo` 6) Test AMDGPU AND/OR RADEON on udev and eudev and see the failure. *) changes in /etc/default/grub for `GRUB_CMDLINE_LINUX="radeon.si_support=1/0 amdgpu.si_support=1/0"` might be required, where 1/0 is either 1 or 0 depending on the configuration to which driver is used. b) eudev which doesn't work on AMDGPU AND/OR RADEON. 1) unmerge udev, emerge eudev 2) Make sure that your eudev has default configuration (even when i tried to configure it and it doesn't have an effect.) 3) Make a kernel configuration for CIK/SI on AMDGPU as modular. 4) emerge `vulkaninfo`. 5) invoke `vulkaninfo` to see the failure. 6) Test AMDGPU AND/OR RADEON on eudev and see the failure. *) Was reproduced on desktop profile. *) changes in /etc/default/grub for `GRUB_CMDLINE_LINUX="radeon.si_support=0 amdgpu.si_support=1"` might be required. c) udev which works with AMDGPU, but does NOT work on RADEON. 1) emerge eudev if udev already present remove it + use default configuration. 2) make a kernel configuration for AMDGPU AND/OR RADEON. 3) emerge `vulkaninfo`. 4) invoke `vulkaninfo` to see the failure. 5) Test AMDGPU AND/OR RADEON on udev and see the failure. Or give me the instruction to provide better feedback + CC it to appropriate dev. Since i was able to reproduce it multiple times on a fresh gentoo installation + i'm not alone as you can see on the gentoo forum. Or what do you expect from me to do? I've package.masked =sys-fs/eudev-3.2.6. (In reply to Anthony Basile from comment #68) > (In reply to KostWarCZE from comment #63) > > > Had no effect, revert changes. > > > > trying 9999 version of sys-fs/eudev. > > > This is not a bug in eudev as far as I can see. Also, both the severity and > priority are normal. Please do not change them. > > I cannot confirm the bug because I cannot reproduce it. It pretty clearly is an eudev bug. It's already fixed upstream no less. Same bug as bug 666892 really. (In reply to Matt Turner from comment #71) > (In reply to Anthony Basile from comment #68) > > (In reply to KostWarCZE from comment #63) > > > > > Had no effect, revert changes. > > > > > > trying 9999 version of sys-fs/eudev. > > > > > > This is not a bug in eudev as far as I can see. Also, both the severity and > > priority are normal. Please do not change them. > > > > I cannot confirm the bug because I cannot reproduce it. > > It pretty clearly is an eudev bug. It's already fixed upstream no less. Same > bug as bug 666892 really. I'm confused by the statement "rebooted and sys-fs/eudev-9999 does NOT have effect on broken vulkan on ATI drivers" because -9999 has the fix for 666892. (In reply to Anthony Basile from comment #72) > (In reply to Matt Turner from comment #71) > > (In reply to Anthony Basile from comment #68) > > > (In reply to KostWarCZE from comment #63) > > > > > > > Had no effect, revert changes. > > > > > > > > trying 9999 version of sys-fs/eudev. > > > > > > > > > This is not a bug in eudev as far as I can see. Also, both the severity and > > > priority are normal. Please do not change them. > > > > > > I cannot confirm the bug because I cannot reproduce it. > > > > It pretty clearly is an eudev bug. It's already fixed upstream no less. Same > > bug as bug 666892 really. > > I'm confused by the statement "rebooted and sys-fs/eudev-9999 does NOT have > effect on broken vulkan on ATI drivers" because -9999 has the fix for > 666892. As I said i'm using 9999 version with fresh sync and the issue is still present.. comment #69 was written based on 9999 and I mentioned in #64. Note that I'm currently on the vacation and my WOL is broken so I can't access my PC with this issue. (In reply to Anthony Basile from comment #72) > (In reply to Matt Turner from comment #71) > > (In reply to Anthony Basile from comment #68) > > > (In reply to KostWarCZE from comment #63) > > > > > > > Had no effect, revert changes. > > > > > > > > trying 9999 version of sys-fs/eudev. > > > > > > > > > This is not a bug in eudev as far as I can see. Also, both the severity and > > > priority are normal. Please do not change them. > > > > > > I cannot confirm the bug because I cannot reproduce it. > > > > It pretty clearly is an eudev bug. It's already fixed upstream no less. Same > > bug as bug 666892 really. > > I'm confused by the statement "rebooted and sys-fs/eudev-9999 does NOT have > effect on broken vulkan on ATI drivers" because -9999 has the fix for > 666892. As I said i'm using 9999 version with fresh sync and the issue is still present.. comment #69 was written based on 9999 and I mentioned in #64. Note that I'm currently on the vacation and my WOL is broken so I can't access my PC with this issue. eudev-9999 works for me (In reply to KostWarCZE from comment #74) > > As I said i'm using 9999 version with fresh sync and the issue is still > present.. comment #69 was written based on 9999 and I mentioned in #64. > > Note that I'm currently on the vacation and my WOL is broken so I can't > access my PC with this issue. (In reply to Perfect Gentleman from comment #75) > eudev-9999 works for me (In reply to Matt Turner from comment #71) > > It pretty clearly is an eudev bug. It's already fixed upstream no less. Same > bug as bug 666892 really. It sounds like there are two bugs going on here. I'll cut a new release of eudev which at least addresses the issues in rule 50. (In reply to Anthony Basile from comment #76) > > It sounds like there are two bugs going on here. I'll cut a new release of > eudev which at least addresses the issues in rule 50. okay at least the one bug (the one reported in 666892) is fixed. can people test 3.2.7 and see if any issue remains. this way we can start separating out the problems. @vulkan loader/layers I can confirm the bug reproduces on SystemD-based system, and I believe it isn't eudev-specific. I also believe it's a standard build dependency linking problem, either based on mesa or something else ( didn't get the full details yet ) emerge --info Portage 2.3.51 (python 3.5.5-final-0, default/linux/amd64/13.0, gcc-7.3.0, glibc-2.27-r6, 4.16.16-stefan x86_64) ================================================================= System uname: Linux-4.16.16-stefan-x86_64-Intel-R-_Core-TM-_i7-7700HQ_CPU_@_2.80GHz-with-gentoo-1.1 KiB Mem: 16297688 total, 3300240 free KiB Swap: 17951436 total, 17950724 free Head commit of repository gentoo: 725c51cfcdc1aa811beefbf36a6fdea448d0f114 Head commit of repository argent-ws: 0ce4e50467cbaf1edadcf172ce950ef57b3422ed sh bash 4.4_p12 ld GNU ld (Gentoo 2.30 p5) 2.30.0 app-shells/bash: 4.4_p12::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl: 5.24.3-r1::gentoo dev-lang/python: 2.7.15::gentoo, 3.4.8::gentoo, 3.5.5::gentoo dev-util/cmake: 3.9.6::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.2-r4::gentoo sys-apps/openrc: 99999::argent-ws sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.14.1-r2::gentoo, 1.15.1-r2::gentoo sys-devel/binutils: 2.30-r4::gentoo sys-devel/gcc: 7.3.0-r3::gentoo sys-devel/gcc-config: 1.8-r1::argent-ws sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers) sys-libs/glibc: 2.27-r6::gentoo Vulkan-layers compilation on multilib ABI_X86="64 32" build failure on mesa-specific libs: # vulkaninfo ========== VULKANINFO ========== Vulkan Instance Version: 1.1.82 ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_intel.so: wrong ELF class: ELFCLASS32 ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_radeon.so: wrong ELF class: ELFCLASS32 /var/tmp/portage/dev-util/vulkan-tools-1.1.82.0/work/Vulkan-Tools-2cfddd146d666efe0ed06ef1d2bc5565821df144/vulkaninfo/vulkaninfo.c:3339: failed with VK_ERROR_INITIALIZATION_FAILED ABI_X86="64" build: [ 97%] Linking CXX shared library libVkLayer_core_validation.so /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -march=x86-64 -mtune=generic -pipe -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fno-strict-aliasing -fno-builtin-memcmp -std=c++11 -fno-rtti -fvisibility=hidden -Wpointer-arith -Wno-unused-function -Wno-sign-compare -Wl,-Bsymbolic,--exclude-libs,ALL -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname,libVkLayer_core_validation.so -o libVkLayer_core_validation.so CMakeFiles/VkLayer_core_validation.dir/core_validation.cpp.o CMakeFiles/VkLayer_core_validation.dir/descriptor_sets.cpp.o CMakeFiles/VkLayer_core_validation.dir/buffer_validation.cpp.o CMakeFiles/VkLayer_core_validation.dir/shader_validation.cpp.o CMakeFiles/VkLayer_core_validation.dir/xxhash.c.o ../libVkLayer_utils.a -Wl,-Bstatic -lSPIRV-Tools-opt -lSPIRV-Tools -Wl,-Bdynamic [ 97%] Built target VkLayer_core_validation make: *** [Makefile:130: all] Error 2 * ERROR: media-libs/vulkan-layers-1.1.82.0::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=media-libs/vulkan-layers-1.1.82.0::gentoo'`, * the complete build log and the output of `emerge -pqv '=media-libs/vulkan-layers-1.1.82.0::gentoo'`. * The complete build log is located at '/var/tmp/portage/media-libs/vulkan-layers-1.1.82.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/media-libs/vulkan-layers-1.1.82.0/temp/environment'. * Working directory: '/var/tmp/portage/media-libs/vulkan-layers-1.1.82.0/work/Vulkan-ValidationLayers-89bbac497742d48c3d483f78b1bba99101784746-abi_x86_64.amd64' * S: '/var/tmp/portage/media-libs/vulkan-layers-1.1.82.0/work/Vulkan-ValidationLayers-89bbac497742d48c3d483f78b1bba99101784746' (In reply to Stefan Cristian Brindusa from comment #78) > @vulkan loader/layers > I can confirm the bug reproduces on SystemD-based system, and I believe it > isn't eudev-specific. > > I also believe it's a standard build dependency linking problem, either > based on mesa or something else ( didn't get the full details yet ) > This bug is about the initial permission error present in sys-fs/eudev. So this comment is not relevant. > # vulkaninfo > ========== > VULKANINFO > ========== > > Vulkan Instance Version: 1.1.82 > > ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_intel.so: wrong ELF > class: ELFCLASS32 > ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_radeon.so: wrong ELF > class: ELFCLASS32 > /var/tmp/portage/dev-util/vulkan-tools-1.1.82.0/work/Vulkan-Tools- > 2cfddd146d666efe0ed06ef1d2bc5565821df144/vulkaninfo/vulkaninfo.c:3339: > failed with VK_ERROR_INITIALIZATION_FAILED > This is either missing support (as noted in the khronos bug above) or a differnt bug in dev-utils/vulkan-loader. Please take the action appropriate to file a new bug for said support or fix. > > ABI_X86="64" build: > > > [ 97%] Linking CXX shared library libVkLayer_core_validation.so > /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -march=x86-64 -mtune=generic > -pipe -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers > -fno-strict-aliasing -fno-builtin-memcmp -std=c++11 -fno-rtti > -fvisibility=hidden -Wpointer-arith -Wno-unused-function -Wno-sign-compare > -Wl,-Bsymbolic,--exclude-libs,ALL -Wl,-O1 -Wl,--as-needed -shared > -Wl,-soname,libVkLayer_core_validation.so -o libVkLayer_core_validation.so > CMakeFiles/VkLayer_core_validation.dir/core_validation.cpp.o > CMakeFiles/VkLayer_core_validation.dir/descriptor_sets.cpp.o > CMakeFiles/VkLayer_core_validation.dir/buffer_validation.cpp.o > CMakeFiles/VkLayer_core_validation.dir/shader_validation.cpp.o > CMakeFiles/VkLayer_core_validation.dir/xxhash.c.o ../libVkLayer_utils.a > -Wl,-Bstatic -lSPIRV-Tools-opt -lSPIRV-Tools -Wl,-Bdynamic > [ 97%] Built target VkLayer_core_validation > make: *** [Makefile:130: all] Error 2 This is a different bug and may or may not be related to bug 666596. If it is different, please file a new bug with the specified details. (In reply to Brian Evans from comment #80) > This is either missing support (as noted in the khronos bug above) or a > differnt bug in dev-utils/vulkan-loader. Please take the action appropriate > to file a new bug for said support or fix. > Whoops, I mean dev-util/vulkan-tools I've reread this bug and I think it was a conflation of two issues. One was fixed (see comment #76). The other looks like it belongs to dev-util/vulkan-tools. Unless I'm missing something, I'm going to close this bug. I'll wait a few days for comments. To Brian Evans: Over and over again.. Based on available informations this is not a permission or vulkan-tools, please stop sabotaging the afford to fix this blocker issue that currently renders vulkan on affected gentoo system as non-functional. > This is either missing support (as noted in the khronos bug above) or a differnt bug in dev-utils/vulkan-loader. Please take the action appropriate to file a new bug for said support or fix. If it's missing any support please update the wiki so that end-users have the ability to diagnose it and fix it themself or provide us info to verify that its missing support.. So far you only replaced my info which temporarely fixed the issue on many affected systems due bug confirmed by upstream as mensioned above and here: https://github.com/gentoo/eudev/commit/a8ffcd1b985fb4b3e2c3a1cb9051bed86f69d3f3 with fix that is not working. Please verify the informations prior to commit next time since your commit made lots of people on Gentoo Discord to lose the vulkan functionality on their gentoo as i tried to explain to you on the email. I'm sorry, but you are so close minded to the point where it negatively affects other people and gentoo foundation in general which i still don't understand why is tolerated nor acceptable. > This is a different bug and may or may not be related to bug 666596. If it is different, please file a new bug with the specified details. Again if you at least read the bug that i've filed you will notice that this bug was filed as issue with vulkan, i'm not responsible for gentoo developers confusing the issue. SUPPLEMENT: Vulkan is working on ubuntu 18.10 running original kernel 4.18.0-11-generic with `mesa-vulkan-drivers` package and changes to blacklist radeon in /etc/default/grub. Affected Gentoo system is confirmed to run on amdgpu with `vulkan-loader` as provided by gentoo and informations from wiki + kernel configuration on AMDGPU with radeon NOT included. https://github.com/KhronosGroup/Vulkan-Loader/issues/108#issuecomment-444164099 Need more info to diagnose. I'm not an expert on vulkan nor 3D rendering on linux, can you (Gentoo Foundation) provide more info so that we know how to diagnose this issue and how to fix it? Is this still an issue? I would of suspected a kernel or mesa issue and a lot has changed in those since 2018. |
