Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 667686

Summary: sys-fs/eudev-3.2.6 installs bad /lib/udev/rules.d/50-udev-default.rules, breaking 3D acceleration
Product: Gentoo Linux Reporter: KostWarCZE
Component: Current packagesAssignee: eudev team <eudev>
Status: CONFIRMED ---    
Severity: normal CC: jstein, mimworkmail, perfect007gentleman, sam
Priority: Normal    
Version: unspecified   
Hardware: AMD64   
OS: Linux   
URL: https://github.com/gentoo/eudev/commit/a8ffcd1b985fb4b3e2c3a1cb9051bed86f69d3f3
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: make.conf
eix-installed -a
emerge --info
vulkaninfo from user
vulkan info on root
/etc/group
root # strace -o trace.log -f -s 1000000 vulkaninfo
user $ strace -o trace.log -f -s 1000000 vulkaninfo
/etc/default/grub
strace -o trace.log -f -s 1000000 vulkaninfouser /tmp $
4.18.4-gentoo - USER vulkaninfo
4.18.4-gentoo - USER vulkaninfo in /tmp
4.18.4-gentoo - strace ROOT vulkaninfo from /tmp.
4.18.4-gentoo - ROOT vulkaninfo.
4.14.65 - USER strace vulkaninfo in /tmp
4.14.65 - USER vulkaninfo.
4.14.65 - ROOT strace vulkaninfo in /tmp.
4.14.65 - ROOT vulkaninfo.
4.14.65 - USER vulkan after chmod.
RADEON - strace -o trace.log -f -s 1000000 vulkanifo from ROOT.
2018-10-15 eix-installed -a

Description KostWarCZE 2018-10-03 23:35:38 UTC
Vulkan is not working on 4.18.9-gentoo, None on IRC knows why, None on Discord knows why, suspect bug.

CPU: I7-2600K

GPU: AMD Radeon 7870

make.conf: http://bpaste.net/show/0c22626770f2

list of installed packages:  http://bpaste.net/show/7140f927a367

emerge --info: http://bpaste.net/show/7d53f2bf693b

vulkaninfo: http://bpaste.net/show/ceee77cfad45

vulkaninfo on root: http://bpaste.net/show/81598b132ae7
(seems to work on root)

User (kreyren) is in video group: 
http://bpaste.net/show/6cb91ba19af2

Selected critical, because my gentoo is brick for gaming atm.

Was able to resolve it before using https://wiki.gentoo.org/wiki/Vulkan#Vulkan_doesn.27t_work_on_user_and_has_issues_in_applications

That fix was temporary.
Comment 1 KostWarCZE 2018-10-04 02:36:23 UTC
Created attachment 549208 [details]
make.conf
Comment 2 KostWarCZE 2018-10-04 02:37:57 UTC
Created attachment 549210 [details]
eix-installed -a
Comment 3 KostWarCZE 2018-10-04 02:38:36 UTC
Created attachment 549212 [details]
emerge --info
Comment 4 KostWarCZE 2018-10-04 02:39:02 UTC
Created attachment 549214 [details]
vulkaninfo from user
Comment 5 KostWarCZE 2018-10-04 02:39:32 UTC
Created attachment 549216 [details]
vulkan info on root
Comment 6 KostWarCZE 2018-10-04 02:40:09 UTC
Created attachment 549218 [details]
/etc/group
Comment 7 KostWarCZE 2018-10-04 02:40:55 UTC
Added files as an attachment on request.
Comment 8 KostWarCZE 2018-10-04 02:52:55 UTC
Created attachment 549220 [details]
root # strace -o trace.log -f -s 1000000 vulkaninfo
Comment 9 KostWarCZE 2018-10-04 02:55:27 UTC
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
Comment 10 KostWarCZE 2018-10-04 03:07:37 UTC
Added `media-libs/mesa vulkan` to `/etc/portage/package.use/custom` in addition to other use flag. no effect on vulkaninfo.+
Comment 11 KostWarCZE 2018-10-04 03:10:15 UTC
Downgraded vulkan-loader and mesa on stable from testing. Same issue
Comment 12 KostWarCZE 2018-10-04 03:13:19 UTC
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.
Comment 13 nvinson234 2018-10-04 03:37:45 UTC
(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.
Comment 14 KostWarCZE 2018-10-04 12:12:12 UTC
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.
Comment 15 Jonas Stein gentoo-dev 2018-10-04 20:22:08 UTC
Do I understand it correct, that it works with other Kernel versions?
Comment 16 KostWarCZE 2018-10-04 22:05:40 UTC
(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.
Comment 17 KostWarCZE 2018-10-04 22:23:12 UTC
(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.
Comment 18 Nick Sarnie gentoo-dev 2018-10-04 22:30:36 UTC
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
Comment 19 KostWarCZE 2018-10-04 22:55:31 UTC
(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.
Comment 20 KostWarCZE 2018-10-04 23:30:08 UTC
Created attachment 549410 [details]
4.18.4-gentoo - USER vulkaninfo

4.18.4-gentoo - USER vulkaninfo
Comment 21 KostWarCZE 2018-10-04 23:32:23 UTC
Created attachment 549412 [details]
4.18.4-gentoo - USER vulkaninfo in /tmp

4.18.4-gentoo - strace USER vulkaninfo invoked from /tmp.
Comment 22 KostWarCZE 2018-10-04 23:33:40 UTC
Created attachment 549414 [details]
4.18.4-gentoo - strace ROOT vulkaninfo from /tmp.

4.18.4-gentoo - strace ROOT vulkaninfo invoked from /tmp.
Comment 23 KostWarCZE 2018-10-04 23:35:02 UTC
Created attachment 549416 [details]
4.18.4-gentoo - ROOT vulkaninfo.
Comment 24 KostWarCZE 2018-10-04 23:37:17 UTC
(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?
Comment 25 KostWarCZE 2018-10-04 23:37:50 UTC
Compiling 4.14.65 next since it's lastest stable in https://packages.gentoo.org/packages/sys-kernel/gentoo-sources.
Comment 26 KostWarCZE 2018-10-04 23:40:43 UTC
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.
Comment 27 Nick Sarnie gentoo-dev 2018-10-04 23:42:43 UTC
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
Comment 28 KostWarCZE 2018-10-05 00:40:10 UTC
Created attachment 549418 [details]
4.14.65 - USER strace vulkaninfo in /tmp
Comment 29 KostWarCZE 2018-10-05 00:40:51 UTC
Created attachment 549420 [details]
4.14.65 - USER vulkaninfo.
Comment 30 KostWarCZE 2018-10-05 00:41:49 UTC
Created attachment 549422 [details]
4.14.65 - ROOT strace vulkaninfo in /tmp.
Comment 31 KostWarCZE 2018-10-05 00:42:45 UTC
Created attachment 549424 [details]
4.14.65 - ROOT vulkaninfo.
Comment 32 KostWarCZE 2018-10-05 00:44:04 UTC
(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.
Comment 33 Nick Sarnie gentoo-dev 2018-10-05 00:46:03 UTC
(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
Comment 34 KostWarCZE 2018-10-05 00:52:24 UTC
(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.
Comment 35 Nick Sarnie gentoo-dev 2018-10-05 00:54:07 UTC
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
Comment 36 KostWarCZE 2018-10-05 00:57:36 UTC
After reboot no effect on vulkaninfo and stat... 

> chmodding the node to 666 would fix your problem

Please provide more info
Comment 37 Nick Sarnie gentoo-dev 2018-10-05 00:59:13 UTC
(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
Comment 38 KostWarCZE 2018-10-05 01:01:21 UTC
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?
Comment 39 Nick Sarnie gentoo-dev 2018-10-05 01:03:40 UTC
As expected, that fixed it. I'm not sure why permissions on that could change.
Comment 40 KostWarCZE 2018-10-05 01:14:57 UTC
(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)
Comment 41 Nick Sarnie gentoo-dev 2018-10-05 01:16:21 UTC
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
Comment 42 KostWarCZE 2018-10-05 01:34:37 UTC
(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
Comment 43 Nick Sarnie gentoo-dev 2018-10-05 01:36:18 UTC
(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
Comment 44 KostWarCZE 2018-10-05 01:50:29 UTC
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.
Comment 45 Nick Sarnie gentoo-dev 2018-10-05 02:15:18 UTC
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
Comment 46 KostWarCZE 2018-10-05 10:48:20 UTC
(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!
Comment 47 KostWarCZE 2018-10-05 20:48:43 UTC
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)
Comment 48 Nick Sarnie gentoo-dev 2018-10-05 22:08:56 UTC
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
Comment 49 Perfect Gentleman 2018-10-06 16:03:23 UTC
confirm
Comment 50 Perfect Gentleman 2018-10-06 16:14:50 UTC
 ~ $ 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
Comment 51 Nick Sarnie gentoo-dev 2018-10-06 18:08:56 UTC
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
Comment 52 KostWarCZE 2018-10-06 19:05:48 UTC
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,
Comment 53 Perfect Gentleman 2018-10-07 14:20:23 UTC
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@"
Comment 54 Perfect Gentleman 2018-10-07 14:21:09 UTC
(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@"
Comment 55 Matt Turner gentoo-dev 2018-10-07 14:23:12 UTC
(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
Comment 56 Perfect Gentleman 2018-10-07 15:10:24 UTC
(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
Comment 57 Matt Turner gentoo-dev 2018-10-07 15:46:17 UTC
Thanks, I'll reassign to eudev.

Cc'ing x11@ just because I'm interested to see the conclusion.
Comment 58 Matt Turner gentoo-dev 2018-10-07 21:21:28 UTC
This is a regression in 3.2.6. It seems to have been fixed upstream. Removing x11@.
Comment 59 KostWarCZE 2018-10-15 09:15:46 UTC
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.
Comment 60 KostWarCZE 2018-10-15 09:18:37 UTC
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.
Comment 61 KostWarCZE 2018-10-15 09:20:00 UTC
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.
Comment 62 KostWarCZE 2018-10-15 10:25:10 UTC
 $ 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"
Comment 63 KostWarCZE 2018-10-15 10:47:16 UTC
(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.
Comment 64 KostWarCZE 2018-10-15 10:56:04 UTC
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.
Comment 65 Perfect Gentleman 2018-10-15 11:10:43 UTC
(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
Comment 66 KostWarCZE 2018-10-16 13:06:19 UTC
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!
Comment 67 KostWarCZE 2018-10-16 20:23:42 UTC
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.
Comment 68 Anthony Basile gentoo-dev 2018-10-16 23:09:50 UTC
(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.
Comment 69 KostWarCZE 2018-10-17 07:17:31 UTC
(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?
Comment 70 Matt Turner gentoo-dev 2018-10-17 22:13:38 UTC
I've package.masked =sys-fs/eudev-3.2.6.
Comment 71 Matt Turner gentoo-dev 2018-10-17 22:16:20 UTC
(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.
Comment 72 Anthony Basile gentoo-dev 2018-10-18 02:54:09 UTC
(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.
Comment 73 KostWarCZE 2018-10-18 06:18:46 UTC
(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.
Comment 74 KostWarCZE 2018-10-18 06:19:02 UTC
(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.
Comment 75 Perfect Gentleman 2018-10-18 09:12:04 UTC
eudev-9999 works for me
Comment 76 Anthony Basile gentoo-dev 2018-10-18 09:34:24 UTC
(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.
Comment 77 Anthony Basile gentoo-dev 2018-10-26 14:01:47 UTC
(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.
Comment 78 Stefan Cristian Brindusa 2018-11-30 04:15:43 UTC
@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'
Comment 79 Jakub Hrbek 2018-11-30 08:37:50 UTC
https://github.com/KhronosGroup/Vulkan-Loader/issues/108

relevant
Comment 80 Brian Evans Gentoo Infrastructure gentoo-dev 2018-12-01 01:07:42 UTC
(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.
Comment 81 Brian Evans Gentoo Infrastructure gentoo-dev 2018-12-01 01:12:13 UTC
(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
Comment 82 Anthony Basile gentoo-dev 2018-12-01 19:49:20 UTC
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.
Comment 83 Jakub Hrbek 2018-12-02 18:48:42 UTC
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.
Comment 84 Jakub Hrbek 2018-12-04 17:17:16 UTC
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?