<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 5/17/23 7:19 AM, Michael Ellerman
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:87r0rfywtf.fsf@mail.lhotse">
      <pre class="moz-quote-pre" wrap="">Gaurav Batra <a class="moz-txt-link-rfc2396E" href="mailto:gbatra@linux.vnet.ibm.com"><gbatra@linux.vnet.ibm.com></a> writes:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Hello Michael,

System test hit the crash. I believe, it was PHYP that resulted in it 
due to number of TCEs passed in to be >512.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
OK. It's always good to spell out in the change log whether it's a
theoretical/unlikely bug, or one that's actually been hit in testing or
the field.
</pre>
    </blockquote>
    <font color="#0432ff">I will submit another version of the patch
      with some changes in the log once I figure out how to Tag it for
      stable (as mentioned below).</font><br>
    <blockquote type="cite" cite="mid:87r0rfywtf.fsf@mail.lhotse">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">I was wondering about the Fixes tag as well. But, this interface, in 
it's current form, is there from the day the file was created. So, in 
this case, should I mention the first commit which created this source file?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
If it really goes back to the origin commit, then it's probably better
to just say so and tag it for stable, rather than pointing to 1da177e4.</pre>
    </blockquote>
    <font color="#0432ff">How to do I tag it for stable? Will it be part
      of the "Fixes:" tag or some other tag?</font><br>
    <blockquote type="cite" cite="mid:87r0rfywtf.fsf@mail.lhotse">
      <pre class="moz-quote-pre" wrap="">

I wonder though is there something else that changed that means this bug
is now being hit but wasn't before? Or maybe it's just that we are
testing on systems with large enough amounts of memory to hit this but
which aren't using a direct mapping?</pre>
    </blockquote>
    <p><font color="#0432ff">From the details in Bugzilla, it does seems
        like the HCALL was previously taking long as well but PHYP was
        more relaxed about it. Now, PHYP is limiting on how long can an
        HCALL take. <br>
      </font></p>
    <p><font color="#0432ff">Below are some excerpts from the Bug:
        202349</font></p>
    <pre class="bz_comment_text" style="font-size: small; margin: 0px; font-family: courier; white-space: pre-wrap; width: auto; word-break: break-word; padding: 2px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><font color="#0432ff">Linux is passing too many counts in H_STUFF_TCE.  The higher the counts,
the longer the HCALL takes.  From a Hypervisor perspective, we cannot stop
Linux from doing this or it will violate the rules in the PAPR (which then
would cause Linux to crash).

The dispatcher team has "tightened the screws" on long running HCALLs by
causing this trap to fire.  From our discussions, they will not put the limits
back where they were before.
</font></pre>
    <br class="Apple-interchange-newline">
    <p>Thanks</p>
    <p>Gaurav<br>
    </p>
    <p><font color="#0432ff"></font></p>
    <blockquote type="cite" cite="mid:87r0rfywtf.fsf@mail.lhotse">
      <pre class="moz-quote-pre" wrap="">

cheers
</pre>
    </blockquote>
  </body>
</html>