<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - xorg-server 1.18.2 freeze desktop on i915"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=94515#c21">Comment # 21</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - xorg-server 1.18.2 freeze desktop on i915"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=94515">bug 94515</a>
              from <span class="vcard"><a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> <span class="fn">Chris Wilson</span></a>
</span></b>
        <pre>(In reply to Leho Kraav (:macmaN :lkraav) from <a href="show_bug.cgi?id=94515#c19">comment #19</a>)
<span class="quote">> (In reply to Chris Wilson from <a href="show_bug.cgi?id=94515#c18">comment #18</a>)
> > 
> > It seems to be in response to a XVidMode requests from the client, so both
> > log spam and excess X11 traffic. The debug log showed that it only the
> > Xext/vidmode.c layer and wasn't causing extra work for the hardware (we were
> > not continuing reprobing the hardware which is what I feared, it's both slow
> > and any time we touch the hardware there be dragons). From my pov, it is
> > cosmetic, but it may also be impacting system performance.

> Thanks for the breakdown. Should this thing be branched off into a separate
> bug? The original problem description also includes freezing and I for one
> don't have that (at least yet...).</span >

Right, I think the GetModeLine spam is a separate issue from the freezing and
separating that out into its own bug report should help prevent it being
forgotten.

<span class="quote">> Would be useful to have a drop-in patch attached here to eliminate the
> cosmetics perhaps. That'd enable further testing 1.18.2 for regressions and
> wouldn't force reverting back. This message flood is really bad.</span >

Looking at the changes, it appears entirely cosmetic. That logging used to
exist in 1.18.1 but was hidden behind a verbosity check, now it is just using a
standard LogMessage():

diff --git a/Xext/vidmode.c b/Xext/vidmode.c
index 7c838f4..e7f9947 100644
--- a/Xext/vidmode.c
+++ b/Xext/vidmode.c
@@ -267,13 +267,13 @@ ProcVidModeGetModeLine(ClientPtr client)
     rep.vtotal = VidModeGetModeValue(mode, VIDMODE_V_TOTAL);
     rep.flags = VidModeGetModeValue(mode, VIDMODE_FLAGS);

-    LogMessage(X_INFO, "GetModeLine - scrn: %d clock: %ld\n",
-               stuff->screen, (unsigned long) rep.dotclock);
-    LogMessage(X_INFO, "GetModeLine - hdsp: %d hbeg: %d hend: %d httl: %d\n",
-               rep.hdisplay, rep.hsyncstart, rep.hsyncend, rep.htotal);
-    LogMessage(X_INFO, "              vdsp: %d vbeg: %d vend: %d vttl: %d
flags: %ld\n",
-               rep.vdisplay, rep.vsyncstart, rep.vsyncend,
-               rep.vtotal, (unsigned long) rep.flags);
+    DebugF("GetModeLine - scrn: %d clock: %ld\n",
+          stuff->screen, (unsigned long) rep.dotclock);
+    DebugF("GetModeLine - hdsp: %d hbeg: %d hend: %d httl: %d\n",
+          rep.hdisplay, rep.hsyncstart, rep.hsyncend, rep.htotal);
+    DebugF("              vdsp: %d vbeg: %d vend: %d vttl: %d flags: %ld\n",
+          rep.vdisplay, rep.vsyncstart, rep.vsyncend,
+          rep.vtotal, (unsigned long) rep.flags);

     /*
      * Older servers sometimes had server privates that the VidMode

will quieten it up again. Though any client actually still using XVidMode
should be fixed!</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>