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:
Version-Release number of selected component (if applicable):
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
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.
It works fine on other boxes with nv as the primary driver, as well as on this
very box using the vesa driver.
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):
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
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.
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,