<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_REOPENED "
   title="REOPENED - [HSW i915 MSI-7817] S4 resume on Haswell causes memory corruption (OOM, ext4_, ...)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=82864#c7">Comment # 7</a>
              on <a class="bz_bug_link 
          bz_status_REOPENED "
   title="REOPENED - [HSW i915 MSI-7817] S4 resume on Haswell causes memory corruption (OOM, ext4_, ...)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=82864">bug 82864</a>
              from <span class="vcard"><a class="email" href="mailto:imre.deak@intel.com" title="Imre Deak <imre.deak@intel.com>"> <span class="fn">Imre Deak</span></a>
</span></b>
        <pre>(In reply to Imre Deak from <a href="show_bug.cgi?id=82864#c6">comment #6</a>)
<span class="quote">> (In reply to Jens from <a href="show_bug.cgi?id=82864#c3">comment #3</a>)
> > In response to the comment posted at bugzilla.kernel.org:
> > 
> > > Jens, have you seen the problem since your last report (with or w/o the fixes)?
> > 
> > No.
> > 
> > > Could you still try if you can reproduce the problem with the latest -nightly
> > > kernel and the same tree with the fixes reverted (resetting to 598ae05fd937 - 
> > > "drm/i915: Emit even number of dwords when emitting LRIs").
> > 
> > I have checked out the linux-drm-nightly tree as of yesterday (3.18rc1,
> > 88a443f45) and have tried several suspend/resume on one machine during "make
> > -j4". Except for one watchdog timeout (networking) I have not experienced
> > any problems except for the fact that the resume seems to take a little
> > longer(?) than with 3.17rc1.

> Ok. Not sure about the extra delay. Perhaps connected to the network
> timeout? But for me the important now is that with -nightly you don't see
> the original (more serious) problem.</span >

Btw, if you want to further debug this delay, you could boot with
initcall_debug which shows you how long the resume/suspend handler for each
driver ran and see if anything took unusually long. Or compare the times with
those you get running on 3.17rc1.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are on the CC list for the bug.</li>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>