Comment 30 for bug 47775

Created an attachment (id=5994)
Xorg.log file of freeze

So, here are the first results. (I'm abroad at the moment, so I have limited
possibilities for testing here.)

Setup: The Radeon driver was modified with ErrorF() function calls as shown
here:

_X_EXPORT Bool RADEONSwitchMode(int scrnIndex, DisplayModePtr mode, int flags)
{
    ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
    RADEONInfoPtr info = RADEONPTR(pScrn);
    Bool tilingOld = info->tilingEnabled;
    Bool ret;
#ifdef XF86DRI
    Bool CPStarted = info->CPStarted;

    if (CPStarted) {
 DRILock(pScrn->pScreen, 0);
 RADEONCP_STOP(pScrn, info);
    }
#endif

    RADEONTRACE(("RADEONSwitchMode() !n"));
    ErrorF ("RADEONSwitchMode entered\n");

    if (info->allowColorTiling) {
 if (info->MergedFB) {
     if ((((RADEONMergedDisplayModePtr)mode->Private)->CRT1->Flags &
  (V_DBLSCAN | V_INTERLACE)) ||
  (((RADEONMergedDisplayModePtr)mode->Private)->CRT2->Flags &
  (V_DBLSCAN | V_INTERLACE)))
  info->tilingEnabled = FALSE;
     else info->tilingEnabled = TRUE;
 }
 else {
     info->tilingEnabled = (mode->Flags & (V_DBLSCAN | V_INTERLACE)) ?
FALSE : TRUE;
 }
#ifdef XF86DRI
 if (info->directRenderingEnabled && (info->tilingEnabled != tilingOld))
{
     RADEONSAREAPrivPtr pSAREAPriv;
     drmRadeonSetParam radeonsetparam;
     memset(&radeonsetparam, 0, sizeof(drmRadeonSetParam));
     radeonsetparam.param = RADEON_SETPARAM_SWITCH_TILING;
     radeonsetparam.value = info->tilingEnabled ? 1 : 0;
     if (drmCommandWrite(info->drmFD, DRM_RADEON_SETPARAM,
  &radeonsetparam, sizeof(drmRadeonSetParam)) < 0)
  xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
      "[drm] failed changing tiling status\n");
     pSAREAPriv = DRIGetSAREAPrivate(pScrn->pScreen);
     info->tilingEnabled = pSAREAPriv->tiling_enabled ? TRUE : FALSE;
 }
#endif
    }
    ErrorF ("RADEON tiling finished\n");

    if (info->accelOn)
 RADEON_SYNC(info, pScrn);
    ErrorF ("RADEON_SYNC finished\n");

    if (info->FBDev) {
 RADEONSaveFBDevRegisters(pScrn, &info->ModeReg);

 ret = fbdevHWSwitchMode(scrnIndex, mode, flags);

 RADEONRestoreFBDevRegisters(pScrn, &info->ModeReg);
    } else {
 info->IsSwitching = TRUE;
 ret = RADEONModeInit(xf86Screens[scrnIndex], mode);
 info->IsSwitching = FALSE;
    }
 ErrorF ("RADEON info->FBdev finished\n");

    if (info->tilingEnabled != tilingOld) {
 /* need to redraw front buffer, I guess this can be considered a hack ?
*/
 xf86EnableDisableFBAccess(scrnIndex, FALSE);
 RADEONChangeSurfaces(pScrn);
 xf86EnableDisableFBAccess(scrnIndex, TRUE);
 /* xf86SetRootClip would do, but can't access that here */
    }
    ErrorF ("RADEON ENABLEDISABLE FB Access finished\n");

    if (info->accelOn) {
 RADEON_SYNC(info, pScrn);
 RADEONEngineRestore(pScrn);
    }
    ErrorF ("RADEON Engine Restore finished\n");

#ifdef XF86DRI
    if (CPStarted) {
 RADEONCP_START(pScrn, info);
 DRIUnlock(pScrn->pScreen);
    }
 ErrorF ("RADEON DRIUnlock finished\n");
#endif

    /* Since RandR (indirectly) uses SwitchMode(), we need to
     * update our Xinerama info here, too, in case of resizing
     */
    if(info->MergedFB) {
       RADEONUpdateXineramaScreenInfo(pScrn);
    }
 ErrorF ("RADEON UpdateXinerama finished\n");

    return ret;
}

The disk was remounted with the sync option (and verfied via /proc/mounts).
Screen Depth was changed to 24 bits and X restarted.

Lbreakout2 was started and - using the "f" key - resolution was switched appr.
5-6 times between fullscreen (640x480) and window mode (1024x768). Switching
was stopped when the system froze. The Xorg.log file is attached. (Sorry,
output is not nicely ordered, as I forgot the carriage returns first...)

Interesting is: The xorg.log file does not show any indications that the freeze
happens between any function calls in RADEONSwitchMode (). To my mind, there
are three possible explanations:

1.) Even with the "sync" option, ErrorF messages are written to disk with a
short delay, resulting in lost messages when the freeze occurs.

or

2.) The freeze "takes some time", e.g. one millisecond, so that, although
initiated in RADEONSwitchMode, the function may finish before the machine
actually locks-up.

or

3.) RADEONSwitchMode does something wrong, so that registers or some settings
are screwed up, but the freeze only happens when one other function somewhere
else tries to use these screwed values.

or

3.) The freeze has nothing to do with RADEONSwitchMode ()

Any ideas? How should I continue best?

I have done the lbreakout test as Michel suggested that it's probably due to
the same bug and it's easier to test. If it makes a big difference I can repeat
the test but use the MergedFB setup and try switching resolutions with xrandr.

Cheers,

Michael