DaemonEngine
Error `radeon: The kernel rejected CS` on ATI R500 on Linux
With an ATI R500 (RV570, Radeon X1950 PRO), when I run the game with the ultra preset (but r_imageMaxDimension 256),
I get from time to time this message printed on console:
radeon: The kernel rejected CS, see dmesg for more information (-22).
I'm running Mesa 24.2.8 on Linux 6.8.
This is very likely an error message from the driver, either from the userspace driver, either from the kernel driver.
The dmesg log says:
[ 1497.702635] ------------[ cut here ]------------
[ 1497.702642] UBSAN: shift-out-of-bounds in /build/linux-Rb6idR/linux-6.8.0/include/linux/log2.h:57:13
[ 1497.702651] shift exponent 64 is too large for 64-bit type 'long unsigned int'
[ 1497.702656] CPU: 3 PID: 213675 Comm: daemon:rcs0 Not tainted 6.8.0-53-generic #55-Ubuntu
[ 1497.702663] Hardware name: Gigabyte Technology Co., Ltd. B450M DS3H/B450M DS3H-CF, BIOS F62d 10/13/2021
[ 1497.702666] Call Trace:
[ 1497.702669] <TASK>
[ 1497.702674] dump_stack_lvl+0x76/0xa0
[ 1497.702686] dump_stack+0x10/0x20
[ 1497.702691] __ubsan_handle_shift_out_of_bounds+0x199/0x370
[ 1497.702705] r100_cs_track_texture_check.constprop.0.cold+0x36a/0x382 [radeon]
[ 1497.702816] ? radeon_cs_packet_next_reloc+0x68/0x1e0 [radeon]
[ 1497.702926] r100_cs_track_check+0x32d/0x800 [radeon]
[ 1497.703037] r300_packet3_check+0xad/0x2c0 [radeon]
[ 1497.703148] r300_cs_parse+0x149/0x160 [radeon]
[ 1497.703260] radeon_cs_ioctl+0x13b/0x330 [radeon]
[ 1497.703375] ? __pfx_radeon_cs_ioctl+0x10/0x10 [radeon]
[ 1497.703481] drm_ioctl_kernel+0xbc/0x120
[ 1497.703490] drm_ioctl+0x2d4/0x550
[ 1497.703495] ? __pfx_radeon_cs_ioctl+0x10/0x10 [radeon]
[ 1497.703547] radeon_drm_ioctl+0x4e/0x90 [radeon]
[ 1497.703547] __x64_sys_ioctl+0xa3/0xf0
[ 1497.703547] x64_sys_call+0x12a3/0x25a0
[ 1497.703547] do_syscall_64+0x7f/0x180
[ 1497.703547] ? __x64_sys_clock_gettime+0xb4/0x110
[ 1497.703547] ? syscall_exit_to_user_mode+0x86/0x260
[ 1497.703547] ? do_syscall_64+0x8c/0x180
[ 1497.703547] ? do_syscall_64+0x8c/0x180
[ 1497.703547] ? do_syscall_64+0x8c/0x180
[ 1497.703547] ? do_syscall_64+0x8c/0x180
[ 1497.703547] ? do_syscall_64+0x8c/0x180
[ 1497.703547] ? irqentry_exit+0x43/0x50
[ 1497.703547] entry_SYSCALL_64_after_hwframe+0x78/0x80
[ 1497.703547] RIP: 0033:0x7f28d4324ded
[ 1497.703547] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
[ 1497.703547] RSP: 002b:00007f28a41ff900 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 1497.703547] RAX: ffffffffffffffda RBX: 00005e6e5bbfa300 RCX: 00007f28d4324ded
[ 1497.703547] RDX: 00005e6e5bc0a308 RSI: 00000000c0206466 RDI: 0000000000000019
[ 1497.703547] RBP: 00007f28a41ff950 R08: 0000000000000000 R09: 0000000000000001
[ 1497.703547] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c0206466
[ 1497.703547] R13: 0000000000000019 R14: 00005e6e5bbe6250 R15: 00005e6e5ba95718
[ 1497.703547] </TASK>
[ 1497.703845] ---[ end trace ]---
[ 2204.093689] [drm:r100_cs_track_check [radeon]] *ERROR* [drm] Buffer too small for z buffer (need 20971520 have 3768320) !
[ 2204.093848] [drm:r100_cs_track_check [radeon]] *ERROR* [drm] zbuffer (1280 4 0 4096)
[ 2204.094017] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 2207.323831] [drm:r100_cs_track_check [radeon]] *ERROR* [drm] Buffer too small for z buffer (need 20971520 have 3768320) !
[ 2207.324005] [drm:r100_cs_track_check [radeon]] *ERROR* [drm] zbuffer (1280 4 0 4096)
[ 2207.324133] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 2219.456926] [drm:r100_cs_track_check [radeon]] *ERROR* [drm] Buffer too small for z buffer (need 20971520 have 3768320) !
[ 2219.457084] [drm:r100_cs_track_check [radeon]] *ERROR* [drm] zbuffer (1280 4 0 4096)
[ 2219.457228] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
…
I'll report it on Mesa but I wonder what is triggering that on our side and if we do something wrong or not…
Wouldn't this be potentially a mesa bug? Why are we even wasting time testing the game on such dinosaur hardware?
If I read the archives correctly, this particular piece of hardware is 19 years old now. Were it human, it would be grown up now.
Do we have a rough guideline on how to proceed with ancient hardware support? On one hand, there is a certain charm in supporting such devices, especially in the open source world. On the other hand, I suppose the burden of support will only increase as time passes.
