Created attachment 29068 [details]
Output of 32bit glxinfo
While running 64bit kernel with enabled Radeon KMS(patched to even enable compat ioctls like michel wrote: https://bugs.freedesktop.org/show_bug.cgi?id=22271#c5 ) I'm unable tu run any 32bit OpenGL program.
All I got is "drmRadeonCmdBuffer: -14"
Allocating 512 x 512 radeon RBO (pitch 512)
Depth renderbuffer size = 16 bits
If needed I'm willing to provide drm debug=1 log.
Created attachment 29069 [details]
Output of RADEON_DEBUG=ioctl with fbotexture
Created attachment 29070 [details]
Output of RADEON_DEBUG=all with fbotexture
Created attachment 29071 [details]
Output of RADEON_DEBUG=ioctl with progs/samples/stencil
Created attachment 29072 [details]
Output of RADEON_DEBUG=all with progs/samples/stencil
In dmesg I have this:
[21491.327145] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser !
[21493.161548] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser !
[21494.806706] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser !
[21496.105809] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser !
[21497.345617] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser !
Created attachment 29251 [details]
Output of RADEON_DEBUG=all with 64bit version progs/samples/stencil
Only real difference I was able to spot between 32bit and 64bit version is size of drm_radeon_cmd_buffer_t. In 32bit it have 16 and 64bit have 32.
Created attachment 29511 [details]
output of glxgears32 to messages with drm.debug=1
This is the output of running glxgears (32bit) to syslog with drm.debug=1 set
suokko on #radeon had me add a patch that basically isolated the problem down to
drivers/gpu/drm/radeon/radeon_cs.c around line 108
chunk_array_ptr = (uint64_t *)(unsigned long)(cs->chunks);
if (DRM_COPY_FROM_USER(p->chunks_array, chunk_array_ptr,
he believes the ptr from userspace is invalid since that memory allocation is failing.
Problem is that user space pointers are invalid in kernel space so we have to copy and convert the data before entering kernel memory space. That is required for all pointers passed to drm.
http://www.cs.helsinki.fi/linux/linux-kernel/2002-06/1512.html has explanation about possible fails in copy.
Which means we need compat ioctl layer to handle the copy. Another option probably would be converting the user-space pointer to kernel address space but I could find how to do that.
Airlied pushed a patch to correct this into libdrm. I believe this problem is now fixed.
Yes I agree, drm commit cdd325b59a17a614b90fc2f8b388175e6d79e3cf fixed this bug.
I'm closing this bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.