<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 05/24/2010 11:12 AM, Markus Kovero wrote:
<blockquote
 cite="mid:938AC6786A9CE64EA17214D592E906050ACAC232F2@exc01.office.nbl.fi"
 type="cite">
  <meta http-equiv="Context-Type" content="text/html; charset=us-ascii">
  <div>
  <div>
  <div>
  <p><span lang="EN-US">&gt;&gt;&gt;
(eg. in solaris) Dell has been aware of the issue for months without<br>
&gt;&gt;&gt; real fix, just workarounds. </span></p>
  </div>
  <p><span lang="EN-US">&gt;&gt;I'm
not sure what "latest" means, but we did manage to find the root<br>
&gt;&gt;cause of the failure where the MSI bit would get stuck - which
also<br>
&gt;&gt;explains why disabling MSI-X worked around it. &nbsp;The right
solution
is<br>
&gt;&gt;to use code already in the driver to manage the timeout on that
bit<br>
&gt;&gt;automatically, which is what we are testing with 5.5+ and
expect in<br>
&gt;&gt;newer RHEL kernels ASAP. </span></p>
  <div>
  <p><span lang="EN-US">&gt;I'm really glad I follow this mailing
list and hence came to know of this problem. If Dell has been aware of
this
issue isn't there some way to notify &gt;users? </span>I have ~300
R410 systems
here and not a word about this. Dell, how do you expect users to find
out!?<br>
  <span lang="EN-US">&gt;</span><br>
  <span lang="EN-US">&gt;</span>-- <br>
  <span lang="EN-US">&gt;</span>Rahul<span> </span></p>
  <p><span> &nbsp; </span></p>
  <p><span lang="EN-US">Even through support it took us couple months
to figure the severity
of the problem, which eventually came to us after we started googling,
not advised
from Dell. It seems they&#8217;re not that interested in keeping user
community
informed about such minor details. </span></p>
  <p><span lang="EN-US"> &nbsp; </span></p>
  <p><span lang="EN-US">From what I&#8217;ve gathered; </span></p>
  <p><span lang="EN-US">Redhat is investigating (includes workarounds) </span></p>
  <p><span lang="EN-US"><a moz-do-not-send="true"
 href="http://kbase.redhat.com/faq/docs/DOC-26837">http://kbase.redhat.com/faq/docs/DOC-26837</a></span></p>
  </div>
  </div>
  </div>
</blockquote>
This should change and this was specifically published for an interim
solution while the permanent fix in the driver was being developed.
(Thanks to Dell)<br>
<blockquote
 cite="mid:938AC6786A9CE64EA17214D592E906050ACAC232F2@exc01.office.nbl.fi"
 type="cite">
  <div>
  <div>
  <div>
  <p><span lang="EN-US"> </span></p>
  <p><span lang="EN-US">and Broadcom made fix in driver-level </span></p>
  <p><span lang="EN-US"><a moz-do-not-send="true"
 href="http://patchwork.ozlabs.org/patch/51106">http://patchwork.ozlabs.org/patch/51106</a>
  </span></p>
  <p><span lang="EN-US">afaik this is driver-level &#8220;timeout&#8221; for stuck
MSI-bit. </span></p>
  <p><span lang="EN-US">Disabling C-states seems to work, I think.
Although it increases
power consumption of the servers. </span></p>
  <p><span lang="EN-US"> &nbsp; </span></p>
  </div>
  </div>
  </div>
</blockquote>
Disabling C-States is not the right fix.<br>
<blockquote
 cite="mid:938AC6786A9CE64EA17214D592E906050ACAC232F2@exc01.office.nbl.fi"
 type="cite">
  <div>
  <div>
  <div>
  <p><span lang="EN-US">What I&#8217;d like to see, is that there should be
lower level
fix for issue, so that non-redhat-glue-fixed systems could work with
c-states
enabled, like they should. </span></p>
  <p><span lang="EN-US"> &nbsp; </span></p>
  <p><span lang="EN-US">Yours </span></p>
  <p><span lang="EN-US">Markus Kovero </span></p>
  <p><span lang="EN-US"> </span></p>
  </div>
  </div>
  </div>
</blockquote>
<br>
The permanent driver fix is upstream and non-redhat Linux OSes should
be able to patch their kernels with this fix. <br>
<br>
Its not possible to fix each distro and kernel but Dell has always
tried to push driver fixes upstream working through its partners to
cater to a wider set of Linux users.<br>
<br>
<br>
<br>
</body>
</html>