FS#17357 - [xf86-video-ati] drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream.
Attached to Project:
Arch Linux
Opened by Florian (monsieur.moche) - Thursday, 03 December 2009, 06:10 GMT
Last edited by Andreas Radke (AndyRTR) - Thursday, 24 December 2009, 09:08 GMT
Opened by Florian (monsieur.moche) - Thursday, 03 December 2009, 06:10 GMT
Last edited by Andreas Radke (AndyRTR) - Thursday, 24 December 2009, 09:08 GMT
|
Details
Description:
I can't run neither Blender nor glxgears. florian@flobox:~$ lspci | grep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4550] florian@flobox:~$ glxinfo | grep 'dir\|rer' direct rendering: Yes OpenGL renderer string: Mesa DRI R600 (RV710 9540) 20090101 TCL florian@flobox:~$ glxgears drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. florian@flobox:~$ dmesg |tail [drm] Resetting GPU [drm] Setting GART location based on new memory map [drm] Loading RV710 PFP Microcode [drm] Loading RV710 CP Microcode [drm] Resetting GPU [drm] writeback test succeeded in 1 usecs I could run them before video-ati was updated from a stable version to a GIT one (which btw sometimes has rendering issues when scrolling in e.g. Firefox). The bug still occurs with aur/xf86-video-ati-git. Looking for info on the Internet, I saw a Ubuntu bug report which seems similar and which has been fixed: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/421245 Additional info: * package version(s) extra/libdrm 2.4.15-1 extra/mesa 7.6-2 extra/libgl 7.6-2 extra/ati-dri 7.6-2 extra/xf86-video-ati 6.12.99.git20091014-1 extra/xf86-video-vesa 2.2.1-1 extra/xorg-server 1.7.2-2 extra/xf86-input-evdev 2.3.1-1 * config and/or log files etc. - no xorg.conf - no special instruction in grub command |
This task depends upon
Closed by Andreas Radke (AndyRTR)
Thursday, 24 December 2009, 09:08 GMT
Reason for closing: Fixed
Additional comments about closing: pkg downgraded, KMS support has been dropped
Thursday, 24 December 2009, 09:08 GMT
Reason for closing: Fixed
Additional comments about closing: pkg downgraded, KMS support has been dropped
When it is still happening with a more recent git shot you should wait for kernel 2.6.32 that will have huge drm changes. It should appear in a few days in our testing repos.
OK so let's wait for the kernel update and I'll keep you informed.
testing/xf86-video-ati 6.12.99.git20091207-1 (xorg-video-drivers)
X.org ati video driver
florian@flobox:~$ yaourt -Qs libdrm
testing/libdrm 2.4.16-1
Userspace interface to kernel DRM services
The bug still occurs with these new packages.
florian@flobox:~$ uname -a
Linux flobox 2.6.32-ARCH #7 SMP PREEMPT Fri Dec 4 15:39:16 CET 2009 x86_64 Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz GenuineIntel GNU/Linux
Glxgears still crashes, but the error message is slightly different:
florian@flobox:~$ glxgears
IRQ's not enabled, falling back to busy waits: 2 0
drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
florian@flobox:~$ dmesg |tail
[drm:r600_cs_packet_next_reloc_nomm] *ERROR* No packet3 for relocation for packet at 45.
[drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014
[drm:r600_cs_legacy] *ERROR* Invalid command stream !
This isn't perfect yet though.
Glxgear raises a fatal error when closing the window.
This is sometimes a 11 error and sometimes a 104 error:
florian@flobox:~$ glxgears
IRQ's not enabled, falling back to busy waits: 2 0
XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0"
after 14663 requests (43 known processed) with 0 events remaining.
florian@flobox:~$ glxgears
IRQ's not enabled, falling back to busy waits: 2 0
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 10058 requests (43 known processed) with 0 events remaining.
There's no such an error when quitting Blender.
Another issue: directly rendered graphics are always on top of the undirectly rendered ones (see attached screenshot). It happens with Blender as well.
But I guess I should file another bug report for this, shouldn't I?