Roughly latest git of ddx, drm and libdrm. Xorg-server git version some weeks old. Confirmed with a full nouveau/linux-2.6 git kernel. NV28, KMS active. Issuing the command 'xrandr -s 800x600' resulted in a kernel hang, a live lock one might say. This was worked around in nouveau/linux-2.6 in the commit "drm/nouveau: bail out if validation fails repeatedly", which allows the kernel to fail gracefully, killing only X instead of the whole system. When 'xrandr -s 800x600' fails, monitor loses signal completely. With the kernel workaround in place, X can be restarted and everything is good again. Note, that sysRq force-fb does restore the mode, but not the virtual console image. Setting Option "EXAPixmaps" "false" in xorg.conf disables the bug, so it is driver pixmap specific. Likely it does not affect NV50 family, or someone would have noticed it.
Created attachment 29265 [details] X log of mode change failing
Created attachment 29266 [details] kernel log The kernel log from boot, with lots of experimenting in between, and the reported failure at timestamp 16400.079421.
The original issue seems to be fixed. First worked around by DRM commit 18895876371e616db9f04652460c1d72174909c3 "drm/nouveau: bail out if validation fails repeatedly" The proper handling of the effect of the bug, DRM commit e6c757cc15b32f995f3aed9a4997ed710b740758 "drm/nouveau: protect against validating the same buffer twice" And the fix to the bug itself in DDX, commit 806eaf6b0b36cb05ca9d883ff4572629812a1d48 "kms: rework fbcon transition" However, changing mode with xrandr while watching TV (cable-tv-card, gxine, with Xv most likely) results in X spinning in kernel and giving up in few minutes. But that's another bug for another day. It too results in monitor switching off.
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.