First the working case. Using 64 bit Fedora 11 Kernel radeon kernel modules from agd5f's r600 branch libdrm from git compile without experimental apis in both 32bit and 64bit binaries mesa from git in both 32bit and 64bit binaries ddx from git With this setup I can get 64bit and 32bit hardware accelerated 3d, most things work well. I tried to do the same thing with the following drm-next kernel 2.6.31-rc9 libdrm from git compiled with experimentals api in both 32bit and 64bin binaries mesa from git in both 32bit and 64bit binaries ddx from git mesa in 64bit mode works well. applications run accelerated with no problem. mesa in 32bit mode fails LIBGL_DEBUG=verbose gears libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so libGL error: failed to get magic libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so file /usr/lib/dri/r600_dri.so /usr/lib/dri/r600_dri.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped also I see in my dmesg ioctl32(gears:4095): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4} arg(ff8ea6cc) on /dev/dri/card0 Looks to me like the 32bit mesa is not properly getting the cmd to the 64bit drm in the kernel. Since I am in Fedora, I am not running 32bit apps in a chroot. 32bit libs are in /usr/lib and 64bit libs are in /usr/lib64.
This is probably a duplicate of bug 22271.
Can you try running 32bit "drmstat -v -O /dev/dri/card0" on problematic kernel? Comparing its output with 64bit version should show what is wrong. If drmstat fails, dmesg will be also valuable.
Both drmstat 32bit and 64 bit give errors when run, they look like this.. 64bit ./drmstat -v -O /dev/dri/card0 No driver available /home/kdekorte/git/drm/tests/.libs/lt-drmstat: error 1 (Operation not permitted) 32bit ./drmstat -v -O /dev/dri/card0 No driver available /home/kdekorte/git/drm-32/tests/.libs/lt-drmstat: error 1 (Operation not permitted) Running under root does not make a difference. Do I need to have X shutdown when I do this? however when I run the 32bit app I get this message from dmesg ioctl32(lt-drmstat:5264): Unknown cmd fd(3) cmd(c0246400){t:'d';sz:36} arg(08058008) on /dev/dri/card0 ioctl32(lt-drmstat:5264): Unknown cmd fd(3) cmd(c0106407){t:'d';sz:16} arg(ffc5cc10) on /dev/dri/card0 ioctl32(lt-drmstat:5264): Unknown cmd fd(3) cmd(c0086401){t:'d';sz:8} arg(ffc5cc08) on /dev/dri/card0
Created attachment 29459 [details] Small ioctl test I meant dristat -v. It actually works. That what I get for mindlessly copying test cases from other bugs. You can also try my small ioctl test I have attached. just run "make" and then "make test" to run test. It should work on KMS, since only on it I had ioctl32 problems.
By the way, I think It's really a duplicate of #22271, I could set it that way, but Michel may disagree with my opinion, so I will wait for his action.
output from make test sudo make test [sudo] password for kdekorte: ./test_ioctl ret 0 val 38296 ./ia32-test_ioctl ret -22 val 0 output from dmesg ioctl32(ia32-test_ioctl:9436): Unknown cmd fd(3) cmd(c0106467){t:'d';sz:16} arg(ffd710c4) on /dev/dri/card0
Created attachment 29460 [details] [review] Small patch based on http://bugs.freedesktop.org/show_bug.cgi?id=22271#c5 Apply patch and recompile radeon.ko(make drivers/gpu/drm/radeon/radeon.ko) to replace old one. You should start the test again after that. If test works(both ret's are 0) after applying patch, #23816 is a duplicate of #22271
Krzysztof, After applying the small patch, the ioctl test works, but 3d still does not work sudo make test [sudo] password for kdekorte: ./test_ioctl ret 0 val 38296 ./ia32-test_ioctl ret 0 val 38296 ./gears IRQ's not enabled, falling back to busy waits: 2 1 do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try adjusting the vblank_mode configuration parameter. drmRadeonCmdBuffer: -14. Kernel failed to parse or rejected command stream. See dmesg for more info. in dmesg [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser !
*** This bug has been marked as a duplicate of bug 22271 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.