I was testing the game Lugaro on M26 (RV410), switching between different resolutions in the game's options menu. The LCD native 1680x1050 made the game cursor very slow, so I chose 1400x1050 (have to quit the game and reenter to take effect). After that I could not go back to 1024x768 (default, works well), only 1400++ resolutions were listed. Then suddenly X froze, but sysrq-B worked. I am not sure if this is a recent regression, because it is the first time I try out different resolutions in this game, and the issue might not be easy to reproduce as it happened after a series of resolution switching.
BTW, I was using mesa classic from git.
Closing as obsolete. If this is still seen on modern kernels (3.2+) please update/reopen
I saw this (or something very similar) on Ubuntu's 3.8.0-27 kernel (but I hope this is useful information anyway -- I doubt it's an Ubuntu issue, and this code doesn't appear to have changed since 3.8), when using alt-enter to toggle fullscreen in dosbox (which worked many times in the past, so it's not easily reproduceable). The NULL pointer is in rdev->gem.objects. I notice that elsewhere, rdev->gem.mutex is held when the list is modified, but it does not appear to be held when traversed in radeon_unmap_vram_bos(). Will ttm_bo_unmap_virtual() ever acquire gem.mutex itself (i.e. can bo->destroy() be called)? It wasn't immediately obvious that it would from reading the code, but if ttm_bo_unmap_virtual() can't cause list entry deletion then why use list_for_each_entry_safe()? Is there something else that ensures that the list won't be modified concurrently with radeon_unmap_vram_bos()?