Red Hat Bugzilla – Bug 181736
connecting to vnc module with X radeon server freezes box
Last modified: 2007-11-30 17:11:24 EST
Description of problem: See below Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.0.1-6.1 xorg-x11-drv-ati-6.5.7.3-3.2 vnc-server-4.1.1-35.1 How reproducible: Every time Steps to Reproduce: 1.Set up the X server for a box with an ATI 9200SE card (radeon module) as a vnc server (Load "vnc") 2.Start the X server 3.Connect to it with vncviewer Actual results: After vncviewer opens the window in which the remote screen would be displayed, it starts painting the window with black, but the box freezes hard part-way through the process. Not even SysRq works. Expected results: It works fine on other boxes with nv as the primary driver, as well as on this very box using the vesa driver. Additional info: I'm yet to try whether disabling DRI would be of any help.
Same error using the "ati" driver, that today's test release configured for me.
This still applies to current rawhide. I found out that, if I switch to VT1 before connecting, then the box won't freeze, but VNC won't work either: the VNC client will repaint only part of the screen before X freezes, and then, most of the times, even after restarting X, some consistent screen corruption ensues. X doesn't actually hang in this case, it just keeps repeating the following lines over and over: (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -22 (EE) RADEON(0): Idle timed out, resetting engine... (**) RADEON(0): EngineRestore (32/32) (EE) RADEON(0): RADEONWaitForIdleCP: CP reset -22 (EE) RADEON(0): RADEONWaitForIdleCP: CP start -22
This is still present in rawhide :-( It appears to only occur on SMP systems; with maxcpus=1, the problem did not occur. Moving the `Load "vnc"' before other modules enabled vnc to not freeze immediately, but it still froze in similar ways to those described in 194043, just faster. Commenting out Load "dri" and Load "glx" didn't make any visible difference.
With the following combination (rawhide-20060726): kernel-xen-2.6.17-1.2449.fc6 xorg-x11-server-Xorg-1.1.1-8.fc6 xorg-x11-drv-ati-6.6.1-5.fc6 vnc-server-4.1.2-3.fc6 vnc just worked. Yay!, I thought. No such luck with the non-xen kernel, though. That was because DRI/drm could not be brought up properly in the xen kernel. I tried both XAA and EXA AccelMethods, to no avail. Option "NoAccel" "on" worked around it, but no other option documented in the man page did, not even Option "RenderAccel" "off", which I was hoping might fix it. Another alternative that now works is to comment out Load "dri". This is most definitely not a vnc problem. It might be a problem in the radeon/dri drivers in X, or in the kernel drm side. Hard to tell.
Removing the Load "dri" was not enough to get around the entire problem, unfortunately. The box still froze after some light use of vnc :-(
Created attachment 133692 [details] panic when the box freezes Armed with a serial console, I managed to capture what the kernel printed before freezing. It talks about an MCE log, but unfortunately there's no time to run mcelog before the logged data is history :-(
Since this bugzilla report was filed, there have been several major updates, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their distribution available. Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.
Reporter, could you please confirm as that the bug is still reproducable? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
It *seems* like this is fixed in F7, but I haven't used vnc lately as often or as heavily as I used to, so I can't quite tell. It surely doesn't freeze right away any more. Thanks,